BBS Toolkit

home *** CD-ROM | disk | FTP | other *** search

/ BBS Toolkit / BBS Toolkit.iso / wildcat / tcdocs.zip / TC-TNET.DOC

Wrap

Text File | 1992-03-01 | 170KB | 3,644 lines

MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 1 ───────────────────────────────────────────────────────────────── TABLE OF CONTENTS CHAPTER 1 - INTRODUCTION . . . . . . . . . . . . . . . . . . 4 HOW TO USE THIS MANUAL . . . . . . . . . . . . . . . . . 4 SYSTEM REQUIREMENTS . . . . . . . . . . . . . . . . . . 5 TECHNICAL SUPPORT SERVICES . . . . . . . . . . . . . . . 6 LIMITED WARRANTY . . . . . . . . . . . . . . . . . . . . 7 DISTRIBUTION POLICY AND COPYRIGHT . . . . . . . . . . . 8 COPYRIGHT . . . . . . . . . . . . . . . . . . . . . 8 THE SOURCE CODE . . . . . . . . . . . . . . . . . . 8 DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . 8 CHAPTER 2 -- INSTALLING TOMCAT . . . . . . . . . . . . . . 11 WHAT IS TOMCAT? . . . . . . . . . . . . . . . . . . . 11 WHY DO I NEED TOMCAT? . . . . . . . . . . . . . . . . 11 WHAT'S NEW WITH TOMCAT 3.02? . . . . . . . . . . . . . 12 UPGRADING FROM A PREVIOUS RELEASE . . . . . . . . . . 14 FIRST TIME INSTALLATION . . . . . . . . . . . . . . . 14 MAKEWILD . . . . . . . . . . . . . . . . . . . . 14 MAIL.BAT . . . . . . . . . . . . . . . . . . . . 15 TOMCAT.CFG . . . . . . . . . . . . . . . . . . . 16 OTHER INSTALLATIONS . . . . . . . . . . . . . . . 16 CHAPTER 3 - TCMAINT - THE TOMCAT CONFIGURATION EDITOR . . . 17 MAIN MENU . . . . . . . . . . . . . . . . . . . . . . 17 CONFIGURATION . . . . . . . . . . . . . . . . . . . . 18 NETWORK SECURITY . . . . . . . . . . . . . . . . . . . 23 NETWORK USER DATABASE . . . . . . . . . . . . . . . . 24 CHAPTER 4 - USING TOMCAT . . . . . . . . . . . . . . . . . 26 WHAT THE CALLER SEES . . . . . . . . . . . . . . . . . 26 HELP FILES . . . . . . . . . . . . . . . . . . . 26 DISPLAY FILES . . . . . . . . . . . . . . . . . . 26 TOMCAT COMMANDS . . . . . . . . . . . . . . . . . . . 27 THE MAIN MENU . . . . . . . . . . . . . . . . . . 27 [D]ownload QWK packet . . . . . . . . . . . 27 [U]pload REP packet . . . . . . . . . . . . 27 [C]onfigure your settings . . . . . . . . . 27 [Q]uit back to BBS . . . . . . . . . . . . . 27 [G]oodbye . . . . . . . . . . . . . . . . . 27 [H] Help with TOMCAT . . . . . . . . . . . . 28 THE CONFIGURATION MENU . . . . . . . . . . . . . 28 [C]onfigure Conferences . . . . . . . . . . 28 [R]eset high message pointers . . . . . . . 29 [U]pload MUSTANG.PTR file . . . . . . . . . 29 [N]ew files scan . . . . . . . . . . . . . . 30 [I]nclude new bulletins . . . . . . . . . . 30 [M]aximum packet sizes . . . . . . . . . . . 30 [T]ransfer protocol . . . . . . . . . . . . 30 [P]acker (archiver) . . . . . . . . . . . . 30 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 2 ───────────────────────────────────────────────────────────────── [Q]uit back to TOMCAT main menu . . . . . . 30 OFF-LINE CONFIGURATION . . . . . . . . . . . . . 31 WHAT THE SYSOP SEES . . . . . . . . . . . . . . . . . 32 STATUS LINE . . . . . . . . . . . . . . . . . . . 32 FILE TRANSFER WINDOW . . . . . . . . . . . . . . 32 CHAPTER 5 - ADVANCED TOMCAT OPERATION . . . . . . . . . . . 33 LOCAL OPERATION . . . . . . . . . . . . . . . . . . . 33 COMMAND LINE SWITCHES . . . . . . . . . . . . . . . . 34 /UPLOAD . . . . . . . . . . . . . . . . . . . . . 34 /DOWNLOAD . . . . . . . . . . . . . . . . . . . . 34 /CONFIGURE . . . . . . . . . . . . . . . . . . . 34 /PRESCAN . . . . . . . . . . . . . . . . . . . . 34 PRESCANNING PACKETS . . . . . . . . . . . . . . . . . 34 NETWORK MAIL OPERATION . . . . . . . . . . . . . . . . 35 NET STATUS . . . . . . . . . . . . . . . . . . . 36 NETWORK USER DATABASE . . . . . . . . . . . . . . 36 MULTI-NODE CONFIGURATIONS USING TCNODE.CFG . . . . . . 37 CHAPTER 6 -- INSTALLING TNET . . . . . . . . . . . . . . . 38 WHAT IS TNET? . . . . . . . . . . . . . . . . . . . . 38 UPGRADING FROM A PREVIOUS RELEASE . . . . . . . . . . 39 FIRST TIME INSTALLATION . . . . . . . . . . . . . . . 39 TNET CONFIGURATION FILES . . . . . . . . . . . . . . . 40 TNET.CFG . . . . . . . . . . . . . . . . . . . . 40 [Hubname].CFG . . . . . . . . . . . . . . . . . . 40 CHAPTER 7 -- TNET COMMAND REFERENCE . . . . . . . . . . . . 42 COMMAND LINE PARAMETERS . . . . . . . . . . . . . . . 42 EXPORT . . . . . . . . . . . . . . . . . . . . . 42 IMPORT . . . . . . . . . . . . . . . . . . . . . 42 HIGH . . . . . . . . . . . . . . . . . . . . . . 42 KEYWORDS . . . . . . . . . . . . . . . . . . . . . . . 42 SYSTEM . . . . . . . . . . . . . . . . . . . . . 43 WORK . . . . . . . . . . . . . . . . . . . . . . 43 QWKDIR . . . . . . . . . . . . . . . . . . . . . 43 REPDIR . . . . . . . . . . . . . . . . . . . . . 43 LOGFILE . . . . . . . . . . . . . . . . . . . . . 43 PACKER . . . . . . . . . . . . . . . . . . . . . 43 APPEND . . . . . . . . . . . . . . . . . . . . . 44 ATFILTER . . . . . . . . . . . . . . . . . . . . 44 VERBOSE . . . . . . . . . . . . . . . . . . . . . 44 TTAG . . . . . . . . . . . . . . . . . . . . . . 44 TCAN . . . . . . . . . . . . . . . . . . . . . . 44 PRIVNAME . . . . . . . . . . . . . . . . . . . . 44 TRANSLATE . . . . . . . . . . . . . . . . . . . . 45 IMPTRANS . . . . . . . . . . . . . . . . . . . . 45 EXPTRANS . . . . . . . . . . . . . . . . . . . . 45 LOCSYSOP . . . . . . . . . . . . . . . . . . . . 45 HUBSYSOP . . . . . . . . . . . . . . . . . . . . 45 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 3 ───────────────────────────────────────────────────────────────── IMPORTTAG . . . . . . . . . . . . . . . . . . . . 45 EXPORTTAG . . . . . . . . . . . . . . . . . . . . 45 CONF . . . . . . . . . . . . . . . . . . . . . . 46 HUBNUM . . . . . . . . . . . . . . . . . . . . . 46 PRIVATE . . . . . . . . . . . . . . . . . . . . . 46 TAG . . . . . . . . . . . . . . . . . . . . . . . 46 NEXTMSG . . . . . . . . . . . . . . . . . . . . . 46 CHAPTER 8 -- NETWORK MAIL CONCEPTS AND OPERATION . . . . . 48 NET STATUS . . . . . . . . . . . . . . . . . . . . . . 48 NETWORK TOPOLOGY . . . . . . . . . . . . . . . . . . . 49 NETIQUETTE . . . . . . . . . . . . . . . . . . . 49 PROCESSING MAIL, STEP BY STEP . . . . . . . . . . . . 50 MAINTENANCE ISSUES . . . . . . . . . . . . . . . . . . 52 DEFINING CONFERENCES . . . . . . . . . . . . . . 52 ORGANIZATION . . . . . . . . . . . . . . . . . . 54 RENUMBERING YOUR MESSAGE BASE . . . . . . . . . . 55 BACKUPS AND CRASHES . . . . . . . . . . . . . . . 55 PERFORMANCE CONSIDERATIONS . . . . . . . . . . . 56 APPENDIX A -- MESSAGE NETWORKS SUPPORTING TOMCAT AND TNET . 58 APPENDIX B -- TROUBLESHOOTING AND ERROR MESSAGES . . . . . 59 APPENDIX C - OFF-LINE XPRESS (OLX) . . . . . . . . . . . . 62 APPENDIX D - FREQUENTLY ASKED QUESTIONS . . . . . . . . . . 63 APPENDIX E - GLOSSARY . . . . . . . . . . . . . . . . . . . 65 INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 4 ───────────────────────────────────────────────────────────────── CHAPTER 1 - INTRODUCTION HOW TO USE THIS MANUAL This documentation is organized for use as an initial setup guide, and as a reference book. Introductory information on TOMCAT and TNET are presented in their respective sections, followed by step-by-step installation and configuration instructions, command reference and advanced topics. Unless you are intimately familiar with TOMCAT and TNET, you should begin with chapter 1 and follow the instructions through chapter 3. After completing the setup material, a full reading of the complete configuration and operational reference is strongly recommended. TOMCAT and TNET are very powerful and configurable programs. There is no substitute for reading the operational reference to become familiar with the numerous features available. After you have installed and run TOMCAT and TNET, the manual will serve as a reference guide. It is indexed extensively. After completing the initial setup you should be able to easily locate material on any topic by checking the Table of Contents or the Index. Don't overlook the sections devoted to Technical Support, the TCMAINT configuration editor, Using TOMCAT and TNET, and Advanced Features. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 5 ───────────────────────────────────────────────────────────────── SYSTEM REQUIREMENTS You MUST be running WILDCAT! BBS version 3.0 S, M or P versions or later to use TOMCAT 3.02. TNET 2.2 is designed to operate with WILDCAT! BBS 2.x or 3.x in the Single Line, Multi-Line and Professional versions only. TNET will NOT work with version 1.x or WILDCAT! TEST DRIVE. TOMCAT 3.02 will NOT work with versions 1.x, 2.x, or WILDCAT! TEST DRIVE TOMCAT and TNET have approximately the same system requirements as WILDCAT! BBS -- if your BBS is running smoothly, chances are TOMCAT and TNET will work with minimal effort on your part. Here is the suggested minimum hardware and software configuration: IBM Personal Computer (or true compatible). 384K (minimum) RAM, 300K for TOMCAT. Hard disk drive. Asynchronous communications (serial port) adapter. Intelligent AT command set modem (internal or external). External modems require an RS-232 cable with the standard 9 pins connected (some modem cables do not have all the pins hooked up). 80 column monochrome or color monitor. Voice-grade telephone connection for modem. PC-DOS or MS-DOS, ver 3.0 or later. Wildcat! BBS version 3.0 or later. Packers/Unpackers -- such as PKZIP/PKUNZIP, LHARC, etc. TNET has some additional requirements: You will need a plain ASCII text editor to create and maintain configuration files. The EDLIN line editor program supplied with DOS is better than nothing at all, but you will probably prefer a more full-featured editor. QEdit from Semware is an excellent, simple to use shareware text editor well suited to creating configuration files. The latest version is available for download from Mustang HQ! BBS. You will, of course, need a communications program so you can exchange mail with your host. Any communications program with a MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 6 ───────────────────────────────────────────────────────────────── scripting language can be used for doing automated mail transfers and, of course, we highly recommend QMODEM for its "Quicklearn" auto-scripting capability. If you are connecting with a WILDCAT! or PCBoard host, we suggest Robocomm -- this Shareware program by Dan Parsons is simple to set up, reliable, and designed specifically for making QWK mail transfers. Finally, common sense dictates that you make regularly-scheduled backups of your system. While we've made every effort to test our software in a variety of environments and configurations, accidents can happen and you could be faced with hours of work re-installing and re-configuring your system should something go wrong. The BACKUP and RESTORE programs supplied with DOS are better than nothing, but a quality backup and restore utility will make the job much easier. TECHNICAL SUPPORT SERVICES TOMCAT and TNET were designed for ease of use, and this manual should contain the answers to most of your questions. Read it first and check the appendices for trouble-shooting procedures. You may first want to call our own WILDCAT! Public-access system at 805-395-0650 and leave a quick question to our technical staff. You will NOT have full access on your first call since we need you to fill out the user database information, such as your password, etc. Your security access will be raised as soon as possible, usually within 24 - 48 hours, providing your WILDCAT! registration information is on file. This method of obtaining support is especially useful if you want expert guidance regarding the most advanced features. Another alternative is CompuServe where we are a part of the PC Vendor Support Forum. You reach us by typing GO PCVENA and then selecting Sub Topic 9. Our PIN is (75236,3312). If you are still unable to find the answer to a question or just need a quick explanation, please call us between 9:00am and 5:00pm Pacific time. You can reach technical support at (805) 334-2240. Support is not available by mail or FAX. When calling for support please: - Have your Wildcat! registration number ready. - Be at your computer with the BBS line clear and your manual handy. A call to your system is often needed to resolve problems. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 7 ───────────────────────────────────────────────────────────────── - Be ready to describe the problem in detail. - If possible, be ready to duplicate the problem on your system. - Please be ready to refer to your DOS manual for questions regarding DOS. A working knowledge of DOS is absolutely necessary. - You can call technical support direct at (805) 334-2240. TOMCAT and TNET are constantly undergoing enhancements and revisions. This is normal software maintenance. The current version of TOMCAT or TNET may be a major or minor release. We can provide the best support to users who are running the current major release, and encourage you to keep your software updated. The cost is minimal and the benefits are great. LIMITED WARRANTY THIS PRODUCT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. THE ENTIRE RISK AS TO THE RESULTS AND PERFORMANCE OF THE PROGRAM IS ASSUMED BY YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU (AND NOT MUSTANG SOFTWARE, INC. OR ITS DEALERS) ASSUME THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. FURTHER, MUSTANG SOFTWARE, INC. DOES NOT WARRANT, GUARANTEE, OR MAKE REPRESENTATIONS REGARDING THE USE OF, OR THE RESULTS OF THE USE OF THIS PROGRAM IN TERMS OF CORRECTNESS, ACCURACY, RELIABILITY, CURRENTNESS, OR OTHERWISE; AND YOU RELY ON THE PROGRAM AND ITS RESULTS SOLELY AT YOUR OWN RISK. MUSTANG SOFTWARE, INC. CANNOT ACCEPT RESPONSIBILITY FOR SYSTEM DAMAGE, LOSS OF PROFIT, OR ANY OTHER SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGE RESULTING FROM THE USE OR INABILITY TO USE THIS PRODUCT. Mustang Software, Inc., DOES warrant to the original licensee of a REGISTERED product that the program disk(s) on which the program is recorded be free from defects in materials and workmanship under normal use and service for a period of ninety (90) days from the date of delivery as evidenced by a copy of your receipt. Mustang Software, Inc.'s entire liability and your exclusive remedy shall be replacement of the disk not meeting Mustang Software, Inc.'s Limited Warranty. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 8 ───────────────────────────────────────────────────────────────── DISTRIBUTION POLICY AND COPYRIGHT COPYRIGHT TOMCAT and TNET software and this document is (C) Copyright 1992 Mustang Software, Inc. All rights reserved. TOMCAT and TNET are Trademarks of Mustang Software, Inc. Any specific hardware/software names used in this document are trademarks of specific manufacturers. Regardless of the method of marketing, TOMCAT and TNET are not in the public domain. It is copyrighted by Mustang Software, Inc. All rights are reserved. The latest versions of TOMCAT and TNET are always available from the Mustang Software HQ! BBS, at 805-395-0650. THE SOURCE CODE The source code for TOMCAT and TNET is not available. This decision gives us the ability to guarantee the integrity of our product in this era of software contamination. It is not available either under the TEST DRIVE concept, or as a Commercial product. DEFINITIONS Throughout the documentation, you may run into technical terms or everyday computer terminology with which you are not familiar. Following are some text examples you may come across: [Enter] This represents the Return or Enter key on the keyboard. If you see this in the text, press the Enter key rather than typing in the string. [Esc] This refers to the Esc key on the keyboard. [Alt][char] [Alt] is always followed by a character which means press and hold the Alt Key and hit the following letter. [Alt][A] means hold the Alt key down and press 'A'. [Ctrl][char] Is executed the same way the [Alt] is handled. You press and hold the Ctrl key and then press the following letter. [Fn] This refers to Function keys 1 through 10. Press the function key matching the [Fn]. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 9 ───────────────────────────────────────────────────────────────── Home Directory This is the directory where your MAKEWILD.DAT file is stored, usually C:\WC30 or a similar name. Node Directory This is the WCWORK\NODExx directory that is created by Wildcat for storing node-specific information. The full path for this directory is usually something like C:\WC30\WCWORK\NODExx where xx is the node number. Net Status Net Status consists of special identifying bits within a QWK packet, allowing it to be imported into a BBS message base. The sysop of the BBS you call for mail must configure your user account for net status in the mail door before TNET will allow you to import mail packets. Net Status has two functions. Firstly, it permits you to upload replies to the mail door from user names other than your own name. Secondly, it prevents unauthorized echoing of BBS messages. Your .QWK packets must have the Net Status identifiers or TNET will abort with an error message when you attempt to import. Hub In the parlance of network topology, a hub is a BBS with a mail door, which is used for network mail exchanges. In a multi-level network a hub may call another hub above it in the tier. The important thing to remember is that a hub uses a mail door to import and export messages from other BBSs to its own system, while a node uses TNET or its equivalent to import and export messages. [Hubname].CFG This is the name of the config file TNET reads in order to gain information about conference number conversions between your own BBS and your hub. It also contains other configuration information specific to each mail hub with which you exchange messages. Node In network mail terms, a node is a BBS which calls a hub system to exchange messages. See Hub, above. A node may also be a hub, and vice versa, depending on the topology of the network. The term "Node" is also used to refer to one line of a multi-line BBS. In this context, it applies to local configuration issues such as environment variables for node ID number, and so forth. QWK Packet The first half of the "raw material" of network MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 10 ───────────────────────────────────────────────────────────────── mail. A QWK packet is created by a mail door, and consists of BBS messages which may be read with an offline reader or, if the packet has "net status", imported with TNET into your BBS for your callers to read. REP Packet The second half of the network mail equation. REP packets (REP is short for REPly) consists of messages which may be uploaded to a QWK mail door for insertion into the host BBS's message base. TNET creates REP packets from your own message base, and imports QWK packets from your host's message base. Mail Door An add-on program for a BBS which allows callers and network nodes to download messages in a compressed format, and upload replies. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 11 ───────────────────────────────────────────────────────────────── CHAPTER 2 -- INSTALLING TOMCAT WHAT IS TOMCAT? TOMCAT is an off-line mail door for WILDCAT! BBS, supporting QWK (Qwikmail) packets, a common off-line message format for Bulletin Board Systems. The QWK mail format was originally developed by Mark "Sparky" Herring, and is now supported by a host of BBS programs and offline mail readers. TOMCAT allows you and your callers to call the BBS, capture new mail in a compressed file, then read and reply to these messages off-line using Off-Line Xpress from Mustang Software, Inc., or any other QWK-compatible mail reader program. Reply files generated by these offline readers can be sent back to TOMCAT, where they will be unpacked and inserted automatically into your Wildcat! message base. TOMCAT also allows you to exchange messages between one BBS and another, even those using software other than Wildcat, by using a mail tosser such as TNet for WILDCAT! BBS, or any of a variety of other QWK-compatible network mail products for other BBS programs. WHY DO I NEED TOMCAT? Everyone who's posted messages on a Bulletin Board System has faced the problem of creating and answering messages online. You need to provide a detailed answer to a difficult question, meanwhile the BBS clock is ticking and the toll charges are mounting up -- and the information you need for your answer may not be easy to retrieve while you're online. TOMCAT saves your callers time and connection charges by allowing them to disconnect from the BBS as soon as they've received their mail packet. This takes only a fraction of the time it would take to read and reply to messages on-line, and allows callers the freedom to read and answer BBS mail at their own convenience while taking advantage of night-time phone rates and less-busy times for your BBS. If you operate your BBS as a hobby, TOMCAT will encourage your callers to participate in the message bases on your BBS, and still allow them time for their favorite activities -- playing door games and downloading files! For a corporate or institutional BBS, TOMCAT will allow your customers and staff to keep up with their mail without tying up your phone lines. This is especially important if you are providing a toll-free number for access to the bulletin board. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 12 ───────────────────────────────────────────────────────────────── TOMCAT can actually save you money. Reducing your callers' on- line time increases the number of calls your system can handle efficiently, and saves money you might otherwise be spending on additional hardware and telephone lines. Finally, TOMCAT allows you to link your BBS and others using the common .QWK mail message format. TOMCAT is an echo-mail capable hub, and interfaces smoothly with .QWK compatible systems on a wide variety of BBS software. WHAT'S NEW WITH TOMCAT 3.02? - Added Alt-D DOS shell. - When console security is set to something other than None in Makewild, the user's password is requested on local startup. - Fixed new files routine so TOMCAT will search only the past week if the user's new files date is older than a year. - Added a new [T]oggle menu on the conference configuration screen that allows callers to Deselect all conferences, Select all conferences for all mail, Select remaining conferences for personal mail only, and Turn off all "personal mail only" selections - User's title is only added if the message's From field is the user's name (for network sysops). - ANSI bulletins are now only set if the user has color configured. - Messages entered into alias conferences now set the addressee's mail waiting flag. - File listing formats in NEWFILES.DAT now match user's default file listing type. - @NODExxx@ is now supported. - Read-only conferences are now supported. - TOMCAT now looks for Local .PTR files in the Local directory as specified in TCMAINT, rather than the Node directory. - If there is only one packer available, the question is skipped. - Packets with no new messages but with new files are now sent. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 13 ───────────────────────────────────────────────────────────────── - ANSI display files now display correctly on local screen. - Incoming messages now truncated to the length specified in Makewild. - If you have an existing local packet, TOMCAT now asks you whether you want to overwrite. If you say no, then it will rename it. - There is now the ability to turn on personal mail only for a conference. By default now, a conference will not be scanned unless you have either selected it for all mail or selected it for personal mail only. WHAT'S NEW WITH TOMCAT 3.01? - Added TCMAINT.EXE setup program to create TOMCAT.CFG file. - Multiple packers are now supported, not just PKZIP - New bulletins, files, and news can optionally be included in mail packets - Duplicate message checking and rejection is now performed - Prescanned mail packets are now supported, as well as saving callers' packets when they encounter a download abort resulting in disconnection - Maximum message limits can be specified by conference and per packet - Short conference names can be explicitly specified - Local command line operation is now supported - New command line switches let you invoke Download, Upload, or Configure directly from the command line - Pointer files are now supported, these are .PTR files which are included in each QWK - Text-only packets are now supported - Private network mail is now supported - Conferences which are set for no high ASCII will have all high ASCII removed by TOMCAT, and in addition TOMCAT will remove any tear bars that exist in uploaded messages MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 14 ───────────────────────────────────────────────────────────────── UPGRADING FROM A PREVIOUS RELEASE Before you run TOMCAT (or any other BBS utility that works directly on your datafiles) for the first time, BACK UP. We'll say it again. BACK UP your important BBS files. If you already have a previous version 3.x of TOMCAT running on your system, the upgrade to version 3.02 is straightforward. First, save a backup copy of your current TOMCAT.EXE, TCMAINT.EXE, TOMCAT.CFG and TOMCAT.OVR files. Then copy the new TCMAINT.EXE, TOMCAT.EXE and TOMCAT.OVR in place of the old ones. If you're running TOMCAT 3.0, you should run TCMAINT to update your TOMCAT.CFG file, press [F10] to save your settings, and [Esc] to exit. This step is not necessary if you are upgrading from TOMCAT 3.01 to TOMCAT 3.02. FIRST TIME INSTALLATION TOMCAT is extremely easy to install and configure. However, the success of your installation depends on having a good understanding of Wildcat and DOS before you start, and reading at least the "INSTALLING TOMCAT" portion of this documentation. Here is the installation procedure, step by step: 1. First, make a backup of your BBS files. 2. Extract the entire contents of TCAT302.ZIP into your Home Directory. Then move TCNEWUSR.BBS to your display directory (or directories if you have different display directories per conference). You may edit this file, if desired, with an ASCII text editor. 3. Next, run TCMAINT to create TOMCAT's configuration file. See the following section for detailed information on using TCMAINT. MAKEWILD The next step in the installation process is to run MAKEWILD, and make a few alterations to your system setup. We recommend setting Wildcat to "swap out" for doors and menu hooks -- this is by far the simplest and most reliable configuration, and requires the fewest modifications to batch files and system configuration. Go to "General Information - Part 2", and change line 4, "Swap out during DOS shells" to "Y". The next change is to the menu definition section of MAKEWILD. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 15 ───────────────────────────────────────────────────────────────── Wildcat! 3.0 has greatly expanded the options on where and how to install TOMCAT. Each menu (MAIN, MESSAGE, FILE and SYSOP) now has at least two "Menu hooks" which, when enabled, will cause Wildcat to execute a batch file and run an external program, or door. The vast majority of Wildcat! sysops install TOMCAT on the Message menu, using the "[N] DOS HOOK", changing the call letter and menu definition to "[D] Download TOMCAT mail". We strongly recommend installing TOMCAT in this manner, to verify that the program is working correctly on your system. Some other options are available -- you may install TOMCAT on the Main Menu, as a [D]oor, or from one or another of the DOS hooks. First, however, we'll install TOMCAT on the [N] DOS HOOK menu selection on Wildcat's message menu. To begin the installation, run MAKEWILD in your Wildcat home directory, and go to the "Message menu definition" screen in MAKEWILD. Cursor down to the "Call MAIL.BAT" function. Change the "Ltr" for that entry from N to D. Then change the "Description" from "[N].................DOS hook" to "[D].....Download TOMCAT mail". Finally, you will need to assign an appropriate security level to that function. If you have created ASCII text file menus which take the place of Wildcat's own menus, you will need to update those screens as well. The next step is the "Door Definition" screen of MAKEWILD. TOMCAT is a multiuser door, and can handle any number of callers concurrently. If you're running the Multi-line or Professional versions of Wildcat, you will need to change the "Multiuser" flag to "Y" for the Mail door to enable this mode. If this is set to "N", all other callers will be kept out of the mail door while it is in use. MAIL.BAT The next step is to install the batch file that starts TOMCAT. Its name is MAIL.BAT If you have installed TOMCAT according to the instructions above, when your caller goes to the message menu and selects [D]ownload mail, Wildcat will then swap out to disk or EMS, then execute MAIL.BAT. The contents of MAIL.BAT should be something like this: ECHO NOW EXECUTING MAIL.BAT \WC30\TOMCAT MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 16 ───────────────────────────────────────────────────────────────── Assuming you start Wildcat from your \WC30 subdirectory, no other commands are necessary, or recommended. The batch file changes to the Wildcat home directory, then executes TOMCAT. When TOMCAT terminates, Wildcat immediately swaps back in and resumes its normal operation. TOMCAT.CFG Your next step is to create a TOMCAT.CFG file, using the TCMAINT setup program. Most of the information TOMCAT requires at runtime is read directly from Wildcat's data files, with the remainder of the necessary information supplied by TOMCAT.CFG. TCMAINT is menu-driven, and has complete on-line help to guide you through the setup process. While you are using TCMAINT, you may wish to consult the next section of this manual for a detailed explanation of each menu selection. Remember to save your settings by pressing [F10]. When you have saved your settings and exited TCMAINT, you should now test installation and verify that TOMCAT is working correctly. Start up Wildcat, and do a local logon. Go to the Message menu, then select Download messages. If you have installed TOMCAT according to the instructions above, Wildcat will shell out and execute MAIL.BAT, and in a few moments you will see the TOMCAT opening screen. You should then try downloading a mail packet locally, to verify that all your paths are correctly set, and that the external programs required by TOMCAT are present in your DOS path or in your \WC30 subdirectory. The next step would be to have someone call into your system over the modem, then enter the mail door and download a packet, to verify that remote connections are working correctly. OTHER INSTALLATIONS If you need to terminate Wildcat for doors and menu hooks, a more complicated setup, including batch files which test for the existence of other batch files, is required. Please read the "Drop to DOS processing" and "Doors" sections of Chapter 7 in your Wildcat manual, beginning on page 217, and "Mail Doors and Off-line Readers" on pages 261-262. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 17 ───────────────────────────────────────────────────────────────── CHAPTER 3 - TCMAINT - THE TOMCAT CONFIGURATION EDITOR TCMAINT.EXE is the setup program for TOMCAT, and is used to create and maintain TOMCAT.CFG, assign network mail security access, and maintain your network mail user database. Here is a list of active keys in TCMAINT: [F1] displays a context-related help screen [F2] displays a pick list of available choices for multiple-choice items. [F10] Saves your settings. [Esc] Exit current screen, abort changes, exit TCMAINT. [Spacebar] Toggles multiple-choice items. MAIN MENU The TCMAINT main menu looks like this: ╒═══════════════════════════════╕ │ TCMAINT Menu │ ├───────────────────────────────┤ │ │ │ Configuration │ │ │ │ Network Security │ │ │ │ Network User Database │ │ │ │ Exit │ │ │ ╘═══════════════════════════════╛ Four options are available to you, the sysop, for editing and manipulation. The first selection, Configuration, is used to create and edit TOMCAT.CFG -- the file which stores your main configuration settings for TOMCAT. To select an item to edit, move the highlight bar using your arrow keys or mouse, and press enter. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 18 ───────────────────────────────────────────────────────────────── CONFIGURATION The first menu selection allows you to edit TOMCAT.CFG. This is a plain ASCII text file consisting of keywords and values, and may be viewed or edited from outside TCMAINT if desired. The individual configuration items are displayed below, with a brief explanation of each item: ──────────────────── BBS Information ───────────────────── ID: MUSTANG The system ID is the name TOMCAT will give your .QWK files. This must be 8 characters or less, and contain valid DOS filename characters. We recommend ID names which reflect the name of your BBS. For example, the ID of the Mustang Software HQ! BBS is MUSTANG. If your BBS is named, for example, "The Friendly BBS", a suitable ID name might be FRIENDLY. City: Bakersfield, CA Phone: (805) 395-0250 The City: and Phone: fields are for information only. The information is included in the packets TOMCAT creates, and is displayed on the TOMCAT opening screen. Local directory: This field specifies where TOMCAT will place packets that have been created locally. If no directory is specified, the packets will be placed in the WCWORK\NODEx under the Wildcat home directory. This is also the directory where TOMCAT will look for local REP packets. Work directory: Under normal circumstances, this should be left blank so that TOMCAT will automatically create and use WCWORK\NODEx\TEMP under the Wildcat home directory, and is the recommended setting for multi-line use. If you run a single line BBS and would like, for instance to use a different drive, or even a RAM disk, you may specify a path to another work area to speed up operation. You should NEVER specify a complete path to a work directory for a multi-line system, because all nodes then will attempt to use the same directory for temporary files. This will cause serious MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 19 ───────────────────────────────────────────────────────────────── problems with corrupted packets, and could even cause TOMCAT to exit with a fatal error! See the section on Advanced Features regarding TCNODE.CFG if you run a multi-line system and would like to place TOMCAT's work directory elsewhere. ──────────────────────── Toggles ───────────────────────── Bulletins: Y News: Y When you update your system bulletins and newsletter file, you may include them by default in the mail packet your callers download. Note that callers are also able to turn these items off in their own individual configuration if they don't want to receive them. Files: Y This option allows your callers to receive a list of new files with their mail packets, if they desire. Detail download: N TOMCAT updates your Wildcat activity log when it executes, and will provide either a simple report or a detailed report. If you answer "N" to Detail download, TOMCAT will log only successful uploads and downloads, the transfer speed, and the total number of messages sent. A sample of a simple report follows: * MENU HOOK (MAIL.BAT) executed at 01:13 * TOMCAT mail packet download successful (CPS = 831) 7 messages sent Detailed logging is also available, by answering "Y" to the Detail download question. A detailed log entry looks something like this: * MENU HOOK (MAIL.BAT) executed at 12:38 * TOMCAT mail packet download successful (CPS = 892) 2 personal messages 18 messages in 003 - WC! Door Help 5 messages in 005 - WC! Net & Echomail Help 118 messages in 100 - WILDCAT! FidoNet Echo 11 messages in 101 - WC-TECH FidoNet Echo MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 20 ───────────────────────────────────────────────────────────────── Detailed logging is useful if you use a third-party program which reads your activity logs and generates a report of online and offline message activity. Reject duplicates: Y Many callers new to the world of offline mail readers forget to delete old reply packets after upload, and send the same replies, plus new ones, on their next call, causing duplicate messages to be placed in your database. If the "Reject duplicates" option is set to "Y", TOMCAT uses a mathematical algorithm to detect new messages which are identical copies of messages already in the database, and rejects the duplicates. TOMCAT will create a MSGxxxx.CRC file for each conference in your message database path, if this feature is turned on. Duplicate checking is especially useful if you have a lot of absent-minded callers who forget to delete old reply packets, or if you participate in BBS networks and wish to prevent duplicate messages from entering the network and echoing to other systems. ───────────────────── Miscellaneous ────────────────────── Propeller: Varied TOMCAT will update the message scanning screen in a variety of ways, depending how this option is set. The options are "Simple", which displays a spinning cursor; "Varied", which displays an assortment of ASCII characters; "Dots", which prints a row of dots on screen during the scan; "Count", which provides a count of the number of messages scanned; and "None", which displays nothing but the name and number of the conference being scanned. Prescan Area: 26 (0 to disable this function) Save packets: None TOMCAT is able to operate in command-line mode during a system event, and create prescanned packets ready for your callers to download. This is especially useful for network mail callers or long-distance callers who would like to minimize their time on line. Its secondary function is to save mail packets for later recovery if a caller accidentally disconnects during a download. The "Prescan Area:" is a regular file area defined in Wildcat, where TOMCAT will place its prescanned mail packets. To prevent callers from viewing or downloading mail that doesn't belong to MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 21 ───────────────────────────────────────────────────────────────── them, TOMCAT adds the file to the database and assigns a random file name to the saved packet, and protects it with the caller's system password. The "Save packets:" options are: "All", meaning that all packets will be saved until they are successfully downloaded; "Net status only", meaning that network mail packets only will be saved; or "None", to disable the Save Packet feature. In order to use the Save Packet feature, you must enter a Wildcat file area in the "Prescan Area:" line above. Baud Rate Max Packet Max Conf ───────── ────────── ──────── This option allows you to configure maximum packet size according to the caller's baud rate. You can, for example, prevent callers with slow modems from staying online forever downloading large mail packets, by limiting the total number of messages they can download per packet. Your callers can also configure their own maximum packet size while online, within these sysop-defined limits. One issue to keep in mind when determining the maximum packet size is the amount of available disk space and memory on your system -- a 1000 message mail packet could easily be 700k or larger in uncompressed form, and requires about twice that much free disk space for packing. If you run a multi-line system, but have limited free disk space available in your TOMCAT work directory, your maximum packet size should take this limitation into account. ──────────────────────── Packers ───────────────────────── TOMCAT allows you to give your callers a choice of which file compression utility they would like to use to create their packets. TOMCAT requires these packers and unpackers to be in your DOS path or in your WILDCAT startup directory. TOMCAT will generate an error message if the packer is not found in the DOS path. The letters, descriptions and command lines shown for each of the packers listed in the default settings will work without modification, and we definitely do not recommend changing command lines unless you are sure you know what you are doing. You may add other packers to this list by selecting a call letter and providing a command line and default extension. Bear in mind, however, that many mail readers attempt to detect the packer type MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 22 ───────────────────────────────────────────────────────────────── used by the mail door, and may fail if an unrecognized packer is used. Likewise TOMCAT may be unable to detect a packer type used for a reply packet, and will generate an error message if it is unable to unpack the replies prior to insertion into the message base. The default packers and their command lines are listed below. You may remove any of the default selections by deleting the call letter. Letter Description Extension ────── ────────────────────────────── ───────── Z PKZIP ZIP Packer: PKZIP -es ! Unpacker: PKUNZIP -o ! A PKPAK ARC Packer: PKPAK -a ! Unpacker: PKUNPAK -r ^D L LHA LZH Packer: LHA a -m ! Unpacker: LHA e -m ! J ARJ ARJ Packer: ARJ a ! Unpacker: ARJ e -y ! ───────────────── Short Conference Names ───────────────── The final configuration setting allows you to substitute the long conference name entered in Wildcat, to a short 10-character name supported by your callers' mail reader programs. If no short name is specified, TOMCAT will take the first 10 valid characters in the long conference name, and include those names in the packet. Below is an example of long and short conference names in use at the Mustang Software HQ! BBS. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 23 ───────────────────────────────────────────────────────────────── Conference Short Name ─────────────────────────────── ────────── 0 - Private E-Mail ONLY Private 1 - WILDCAT! Version 3.xx WILDCAT!3 2 - WILDCAT! Version 2.xx WILDCAT!2 3 - WC! Door Help DoorHelp 4 - WC! Ext. Protocol Help ExtProtos 5 - WC! Net & Echomail Help Net&Echo 6 - WC! Modem Operation Help ModemHelp 7 - WC! LANtastic Net Help LANtastic 8 - WC! Novell Network Help Novell 9 - WC! DESQview Help DESQview 10 - WC! TOMCAT/TNet Help TOMCAT 11 - WC! Sysop Chit-Chat SysopChat 12 - WC! BBS Advertisements BBSAds 13 - WC! PRO! Series Help PRO!Help 14 - WC! 3rd Party Util. Help 3rdParty You can see, for example, that the long names for conferences 1 and 2 are the same for the first 10 characters. TOMCAT's short name for both conferences would then be the same, and would likely confuse callers and cause them to post messages in the wrong conference. By changing the short name for conferences 1 and 2 to WILDCAT!3 and WILDCAT!2 respectively, we can keep our long descriptive conference names for online reading, and still have a meaningful name for the shorter conference description field in the .QWK mail packet. NETWORK SECURITY This section of TCMAINT is used to assign network security access (for network mail transfers) to various security profiles in Wildcat. It has nothing to do with operating a BBS on a Local Area Network, but is used to allow other Bulletin Board Systems to exchange messages with you in an echomail network. Normally, TOMCAT will reject messages uploaded by a caller if the "from" name in the message does not match the name of the logged- in caller. This is a security feature to prevent callers uploading messages using alias names. Network Security allows a caller to upload messages that are "from" other user names. TOMCAT also places an identifying flag on these messages in order to prevent duplicate messages from bouncing from one system back to another. Lastly, the message packets generated by TOMCAT for callers with network security can be imported into other Bulletin Board MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 24 ───────────────────────────────────────────────────────────────── Systems using a QWK-compatible network mail tosser such as TNet for Wildcat, or QNet for PCBoard. For security reasons, non net- status packets cannot be imported by any of these message tossers. Setting a network security toggle for a security profile causes TOMCAT to send special net status packets to all callers within that security profile. Please see the "Advanced Features" section of this manual for a more detailed instructions on how to use TOMCAT in an echomail network. A typical Net Security pick list is shown below. Net security can be toggled on and off for each security profile, by using the spacebar. You will note that the security profiles STAFF and NETSYSOP both have net security in this list. ░░░░░░░░░░░░░░░╒══ Net Security ══╕░░ ░░░░░░░░░░░░░░░│ ( ) - BETA-S ░░ ╒══════════════│ ( ) - ALPHA ░░░ │ TCMAI│ (∙) - STAFF ░░░ ├──────────────│ ( ) - BETA-M ░░░ │ │ ( ) - BETA-P ░░░ │ Configuration│ ( ) - TD-CALLER ░░░ │ │ ( ) - NEWUSER ░░░ │ Network Secur│ ( ) - HOLD-HERE ░░░ │ │ ( ) - QMODEM_REG ░░░ │ Network User │ ( ) - QWAITING ░░░ │ │ ( ) - WCAT!_REG ░░░ │ Exit │ (∙) - NETSYSOP ░░░ │ │ ( ) - OLX/SLMR ░░░ ╘══════════════╘══════════════════╛░░ NETWORK USER DATABASE The network user database contains a list of user names, and the node they "belong" to. This function will be discussed in more detail in the "Advanced Features" section of this manual. A sample Network User Database window is below, and shows users who have posted echomail messages originating from the MSI CANADA node: MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 25 ───────────────────────────────────────────────────────────────── ╒═════════════════ Network User Database ══════════════════╕ │Name Node │──────────────────────────────────────────────────────────▓ │(node entry) MSI CANADA ░ │A ABOLINS MSI CANADA ░ │AARON BARNES MSI CANADA ░ │ABE BLOOM MSI CANADA ░ │ADDISON CHING MSI CANADA ░ │ADRIAN REEDY MSI CANADA ░ │AL HOLLISTON MSI CANADA ░ │AL SANDE MSI CANADA ░ │AL THOMPSON MSI CANADA ░ │ALAIN HANASH MSI CANADA ░ │ALAN BURGSTAHLER MSI CANADA ╘══════════════════════════════════════════════════════════╛ MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 26 ───────────────────────────────────────────────────────────────── CHAPTER 4 - USING TOMCAT WHAT THE CALLER SEES HELP FILES Two help files are available to your users. They are TOMCAT.HLP and TCONFIG.HLP. If these files exist in your Wildcat HELP file path, TOMCAT's menus will display "[?] Help" as a command line option, and will display the appropriate help file if a caller selects this option. DISPLAY FILES TOMCAT has two display files, which, if they exist in your Wildcat! conference display file path, will be shown to callers when they enter the TOMCAT mail door. The first display file is TCNEWUSR.BBS. This file is displayed the first time a new caller enters TOMCAT. It may contain a brief message from the sysop welcoming the caller and requesting her to visit the [C]onfiguration menu to select conferences, protocols, etc. A sample TCNEWUSR.BBS is included with TOMCAT. The second display file, TOMCAT.BBS, will be displayed in place of the regular TOMCAT opening screen, if the file exists in your conference display file path. This allows you to create a custom screen for TOMCAT if you prefer, rather than using the default internally-generated screen. Note that if different WILDCAT conferences have different display file paths, you will need to create a copy of these display files in each path if you want these files to be displayed to all your TOMCAT users. This does allow you to make conference-specific display files for TOMCAT. TOMCAT may also be installed as a Door from the main menu, or from one or another of the available DOS hooks on other menus. The installation process is straightforward -- simply substitute the batch file names and menu selections where appropriate. You may also wish to consult the "Advanced Features" section of this document for information on how to customize your TOMCAT installation by starting in other modes, using command line switches. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 27 ───────────────────────────────────────────────────────────────── TOMCAT COMMANDS TOMCAT is organized into two main sections: the main menu, and the configuration menu. From the main menu, the caller can download and upload mail packets, log off, quit back to the BBS, or call the Configuration menu. Each main menu and configuration menu command will be discussed below: THE MAIN MENU [D]ownload QWK packet TOMCAT will begin scanning all open conferences for new mail. The number and name of each conference, the number of messages, high message number and last-read message number are displayed, along with a running total of messages packed during this session. When all message conferences have been scanned, TOMCAT asks the caller if she wants to receive the packet, offering "Yes", "No", and "Goodbye after transfer" as options. If the caller selects "Yes" or "Goodbye after transfer", TOMCAT will then shell to DOS and execute the selected packer utility to compress the packet and prepare it for download. TOMCAT will then return from DOS, and prompt the caller to begin downloading. [U]pload REP packet TOMCAT will prompt the caller to begin uploading her reply packet. When the upload is complete, TOMCAT will shell to DOS and unpack the reply packet, scan its contents, and insert the messages into your Wildcat message conferences. [C]onfigure your settings Changes to the Configure menu. More on this below. [Q]uit back to BBS Exits from TOMCAT, and returns to Wildcat BBS. [G]oodbye Logs off the caller, and exits back to the Wildcat call- waiting screen. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 28 ───────────────────────────────────────────────────────────────── [H] Help with TOMCAT Displays TOMCAT.HLP from the HELP path. THE CONFIGURATION MENU [C]onfigure Conferences This selection brings up another sub-menu, allowing callers to select conferences in the same manner as the [U]pdate conferences selection on Wildcat's message menu. In fact, these two work interchangeably. Changes made in TOMCAT to your selected conferences will affect on-line message reading within Wildcat, and vice versa. A sub-menu prompt is displayed after the conference list: Enter #, [L]ist, [+]Next, [S]ort, List [A]ll, List [O]nly selected, [T]oggle menu, or [ENTER] to quit? To select or deselect a conference, enter the conference number. The next prompt will be displayed: Do you want to scan "WILDCAT! Version 3.xx" [Y/n]? Answering "N" to this prompt will remove the conference from your selection list. Answering "Y" will display the following sub-menu: Message numbers in this conference range from 6492 to 10784. Current is 10769. Enter new message pointer, [H]elp, [ENTER = no change]: The message pointer referred to in this menu is the number of the last message the caller read in this conference. This is stored in their user record, and may be moved back if the caller wishes to reread mail, or forward if the caller wishes to skip over old unread mail. There are four methods of setting your high message pointer - by number, by percentage of total messages in conference, or by date. Examples: 10 Sets your message pointer to 10 -10 Gives you the last 10 messages 10% Gives you the last 10% of total number of messages 01/16/92 Gives you all messages since [date] MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 29 ───────────────────────────────────────────────────────────────── Sort by [N]ame or [C]onference number [n/c]? The conference list may be sorted by name or number. The default sort is by conference number. [R]eset high message pointers Displays the following screen: Message numbers in this conference range from 6492 to 10784. Current is 10769. Enter new message pointer, [H]elp, [ENTER = no change]: The message pointer referred to in this menu is the number of the last message the caller read in this conference. This is stored in their user record, and may be moved back if the caller wishes to reread mail, or forward if the caller wishes to skip over old unread mail. There are four methods of setting your high message pointer - by number, by percentage of total messages in conference, or by date. Examples: 10 Sets your message pointer to 10 -10 Gives you the last 10 messages 10% Gives you the last 10% of total number of messages 01/16/92 Gives you all messages since [date] [U]pload MUSTANG.PTR file Mail packets created by TOMCAT 3.01 and higher contain a pointer file. This file is an image of the high message numbers before and after the last mail packet download. It is useful for resetting pointers after a failed transfer, or to recover lost messages if a packet is accidentally deleted. To use this function, the caller must first extract the <BBSID>.PTR file from the last .QWK packet she successfully downloaded. From the [C]onfigure menu of TOMCAT, select [R]eset message pointers, then upload the <BBSID>.PTR when prompted. After the upload, the caller will see the following screen: MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 30 ───────────────────────────────────────────────────────────────── This pointer file is dated 12-18-1991 at 07:46:18. Do you want to reset pointers [B]efore or [A]fter this pointer file [B/a]? This selection allows the caller to recover a failed download or lost packet, by setting pointers either before or after the previous download. [N]ew files scan [I]nclude new bulletins These two options ask the caller whether to include a list of new files, and a copy of any new system bulletins since her last login. Note that the sysop may disable these functions in TCMAINT by toggling New Files or Bulletins to "N". [M]aximum packet sizes Callers may set their own maximum packet size, within the limits set by the sysop in TCMAINT. This is useful for callers who download mail packets to a floppy disk, or who use a mail reader which reads only a limited number of messages per conference -- typically 200. This option allows callers to select maximum messages per conference, and per download. [T]ransfer protocol Selecting a default protocol in TOMCAT has the same effect as selecting the default protocol in Wildcat. Changes made in TOMCAT will be reflected in your Wildcat settings. [P]acker (archiver) Where more than one type of packer (file compression utility) is offered by the sysop, TOMCAT will invite callers to select a default packer. [Q]uit back to TOMCAT main menu Returns to the TOMCAT main menu. [H]elp with TOMCAT Displays TCONFIG.HLP in the help file path. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 31 ───────────────────────────────────────────────────────────────── OFF-LINE CONFIGURATION Callers have the ability to send control messages to TOMCAT to make many configuration changes and conference selections using their mail readers. Callers can add, drop and reset conferences, using the features of their mail reader to generate control messages. TOMCAT will honor control messages addressed to TOMCAT or QMAIL, in the following format: Date: 01-27-92 (13:57) Number: 0 From: GWEN BARNES Refer#: NONE To: TOMCAT Recvd: NO (PVT) Subj: ADD Conf: (0) Private [followed by blank message]. This message would add to the caller's scan the conference in the Conf: line of the header. Date: 01-27-92 (13:57) Number: 24 From: GWEN BARNES Refer#: NONE To: TOMCAT Recvd: NO (PVT) Subj: DROP Conf: (24) BetaWMecho This message would drop the named conference from the caller's scan. Date: 01-27-92 (13:57) Number: 22 From: GWEN BARNES Refer#: NONE To: TOMCAT Recvd: NO (PVT) Subj: RESET 0 Conf: (22) Beta3rdPar This message would reset the message pointers in the named conference to the number in the Subj: line. RESET -10 would reset pointers back 10 messages from the top. RESET 01/01/92 would reset pointers to January 1, 1992. RESET 10% would set pointers 10 per cent below the high message number in the conference. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 32 ───────────────────────────────────────────────────────────────── WHAT THE SYSOP SEES TOMCAT displays some additional information on the local screen which is not transmitted to the caller. For instance, when TOMCAT shells to DOS and executes a packer, the packer will write to the local screen but not to the modem port. TOMCAT also displays a local status line and, during a file transfer, a status window. STATUS LINE TOMCAT provides a one-line status bar at the bottom of the screen, indicating version number, caller's name and security profile, the node number and time remaining for the current call. FILE TRANSFER WINDOW The file transfer window is an attractive full-screen window with a "gas gauge" status bar showing the progress of the transfer, plus information on port, connect speed, protocol and characters per second. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 33 ───────────────────────────────────────────────────────────────── CHAPTER 5 - ADVANCED TOMCAT OPERATION LOCAL OPERATION TOMCAT can be run from DOS if desired by the sysop and other users wishing to run it locally, without logging onto Wildcat! first. It requires your user name on the command line, and depending on the "console security" setting in MAKEWILD, may then prompt you for your Wildcat! password before running the door locally. There are some cautions you need to keep in mind when running TOMCAT locally. First, you must run it with a valid WCNODEID number that is not currently in use by any other active node. This is critically important with single-line systems as well. YOU RISK DATABASE CORRUPTION OR SECURITY VIOLATIONS if you use duplicate node numbers. If you own the 'S' version of Wildcat!, or if you are using a multi-line version of Wildcat! with the network type specified as 'Single line', you must either run TOMCAT only as a door while logged on to Wildcat!, or you must take your Wildcat! node DOWN to run TOMCAT locally from the DOS prompt. TOMCAT allows local logons from the DOS command line in the format: TOMCAT GWEN BARNES [Enter] or TOMCAT SYSOP [Enter] If the sysop has set console security in Makewild to "Password" or "No console", TOMCAT will prompt the user to enter his password before continuing. If the console security is set to "None", TOMCAT bypasses the password prompt and goes directly to the TOMCAT main menu. Local download packets are created in the path defined in TCMAINT. If no path is specified, the packet will be created in the node subdirectory below \WC30\WCWORK. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 34 ───────────────────────────────────────────────────────────────── COMMAND LINE SWITCHES TOMCAT may be started with command line switches, which bypass the main menu prompts and go directly to the function specified. These may be used in local mode with your user name, or in a batch file. Running TOMCAT with command line switches allows you to define extra DOS hook menu prompts in Wildcat to provide "express line" access to the TOMCAT functions your callers want. This helps TOMCAT appear to be even more an integrated part of Wildcat, if desired. For example, you may define the following menu keys on your message menu: [D]ownload mail (TOMCAT /DOWNLOAD, using N DOS Hook and MAIL.BAT) [U]pload mail (TOMCAT /UPLOAD, using X DOS Hook 1 and MSG1.BAT) [C]onfigure TOMCAT (TOMCAT /CONFIGURE, using Y DOS Hook 2 and MSG2.BAT) Of course, you would then have to reassign the [U]pdate Conf Scan/Read to another key to avoid conflicts. Here is a list of valid command line arguments: /UPLOAD Goes directly to the "Upload" prompt. /DOWNLOAD Immediately begins scanning for download. /CONFIGURE Goes directly to the "Configure" menu /PRESCAN Prescans a packet offline for later download. See detailed explanation below. PRESCANNING PACKETS Network nodes and other regular callers, particularly those calling long distance, might appreciate being able to download a pre-scanned mail packet, rather than wait online while TOMCAT scans and packs their messages. To create prescanned packets, you must first designate a prescan packet area in TCMAINT. You may select any valid file area in Wildcat, but we recommend that it be one for which your your callers do not have download access, as TOMCAT regulates access to that area by itself. The prescan files will be password- protected with the caller's logon password, and the file names will be scrambled. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 35 ───────────────────────────────────────────────────────────────── You can create prescanned mail packets during a system event by calling TOMCAT from a batch file with the following syntax: TOMCAT [USER NAME] /PRESCAN where [USER NAME] is the name your caller uses to log onto the BBS. TOMCAT will then scan and pack a mail packet, and store it in the Wildcat file area you designated in TCMAINT. If a prescan packet exists, the caller will be prompted to download or delete it. When the caller has successfully downloaded the prescanned packet, TOMCAT will delete it. If a prescanned packet for a caller already exists when TOMCAT is called with the /PRESCAN argument, TOMCAT will skip the prescan, and note this in the activity log. This is to prevent callers from losing mail if they do not pick up their prescanned packet. NETWORK MAIL OPERATION TOMCAT 3.02 generates net status QWK packets recognized by Tnet, Qnet and RNet. This allows TOMCAT to be used as a network mail "hub", allowing other Bulletin Board Systems running Wildcat! BBS or PCBoard to share your message base. QWK/REP mail, developed originally by Mark "Sparky" Herring, is the system of choice on a growing number of BBS networks, and is the mail system supported by TOMCAT It adheres to a published, documented file format, and has the advantage of being supported by many third-party authors and BBS software programs. A wide selection of mail readers, mail doors, and message import/export utilities are available. TOMCAT fully supports QWK/REP network mail for Wildcat! and is compatible with Tnet, RNet and QNet. Here's how a typical network mail transaction works: Imagine yourself as the "hub" of your own network, with one or more "nodes" calling for mail. You've set up a user account in Wildcat for "Fred's BBS" with a security profile of NETSYSOP (or another security profile with net status toggled on in TCMAINT). The sysop of "Fred's BBS" now logs on, enters the mail door, and downloads a QWK packet. After Fred successfully downloads a packet, he now uploads the reply packet he prepared before calling. This reply packet consists of new messages exported from his own BBS, which TOMCAT unpacks and inserts into your message file. The sysop then disconnects from your BBS, and processes his MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 36 ───────────────────────────────────────────────────────────────── newly-received mail packet with RNet or QNet (if Fred's BBS is running PCBoard software); TNet if he operates a Wildcat! BBS. The messages are inserted into Fred's BBS message file(s), Fred the sysop restarts his BBS, and waits for the next mail processing event to roll around. Just before Fred's next call, he exports all the new mail he and his callers have left on his BBS into a REP packet, using RNet, TNet or QNet. Export complete, he calls your BBS again, enters the TOMCAT mail door, uploads the replies, and downloads a fresh QWK packet. NET STATUS By default, TOMCAT sends net status mail packets to callers whose security profile is NETSYSOP. You may assign net status to other security profiles by toggling them in TCMAINT. You should only assign net status to security profiles which will actually be transferring network mail, as offline mail readers are frequently unable to open mail packets generated by TOMCAT in net status mode. Net status is granted in ALL message conferences accessible to a given security profile. If you do NOT want certain message areas on your BBS echoed to other systems, do NOT include them in the conference access portion of that security profile! NETWORK USER DATABASE Under ordinary circumstances, TOMCAT will only send private mail addressed to user names matching the user name of the caller downloading the mail, unless that caller has sysop access. This makes network transfers of private messages awkward, as it would be necessary for a network mail caller to have access to ALL the private mail on your system in order to transfer private mail to his own users. TOMCAT solves that problem by keeping a database of user names. If a caller on another BBS enters a message, and that message is uploaded to TOMCAT by a net status caller, TOMCAT records the caller's name and the user name of the originating node. For instance, if a caller named GREG HEWGILL posts a message which is then uploaded to MSI HQ! BBS in a REP packet by a net status caller named MSI CANADA, Greg's name and the name of the net status caller would automatically be recorded in the network user database, along with the node his message originated from. If a caller leaves a private message for Greg Hewgill on the MSI HQ! BBS, TOMCAT will add that message to the next net status QWK packet downloaded by MSI CANADA. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 37 ───────────────────────────────────────────────────────────────── TCMAINT gives sysops the ability to view and edit names in the network user database, if desired. This may be useful if you need to enter names into the database before the connecting node has made a transfer, or if you need to delete names or nodes from the database. MULTI-NODE CONFIGURATIONS USING TCNODE.CFG This file, if it exists in your \WC30\WCWORK\NODEx directory (where x is a Wildcat node ID number), will over-ride the main \WC30\TOMCAT.CFG with node-specific settings. This is useful if you need, for example, to specify a local drive or a RAM drive for TOMCAT's work directory rather than a network drive. This file is in the same format as TOMCAT.CFG, and can be created by copying TOMCAT.CFG to each node directory. Using a plain ASCII text editor (for example OLXED.EXE, supplied with Off-Line Xpress), you may then make changes to the config for each node. TCNODE.CFG should contain ONLY the lines which over-ride the main TOMCAT.CFG settings -- the rest should be deleted. The file is in a straightforward KEYWORD=ARGUMENT layout, and should be readily understandable. Here is one example of a TCNODE.CFG which overrides the default local directory and work directory on a network node which has a local C: drive. This would create QWK packets on a local drive rather than on a network drive, and would speed up packet assembly by creating packets on the local drive as well. LOCAL = C:\QMODEM\OLX WORK = C:\TC$WORK Since these are the only two items which differ in the configuration from the main TOMCAT.CFG, this is the only information this file needs to contain. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 38 ───────────────────────────────────────────────────────────────── CHAPTER 6 -- INSTALLING TNET WHAT IS TNET? One of the more interesting and useful applications for BBS communications is the ability for one Bulletin Board System to exchange public messages and electronic mail with other systems. These networks can be small and private, such as a link between BBSs belonging to branch offices of a corporation, or they can be large public networks allowing many hobby systems to share messages locally, regionally, or even world-wide. Several standards for network mail have evolved, each with their own advantages and limitations. The oldest and most widespread networking system for personal computers is probably Fido mail. Another system is PCRelay(tm). A third option, and the one we have chosen to adopt with TNET, is based on Mark "Sparky" Herring's Qmail or QWK/REP system. This dual-purpose system allows BBS callers to download, read and reply to messages offline through a mail door. It also allows BBSs to exchange mail with each other in a similar fashion, using the same mail door plus a utility such as TNET for exporting and importing message packets from their own systems. TNET allows you, the sysop, to exchange mail with any host system which uses a QWK-compatible mail door capable of producing "net status" mail packets. TNET extracts outgoing mail from your BBS message base and creates a reply packet that you upload to your host's mail door. You then download a "net status" message packet from your host, and import the new mail into your BBS message base with TNET. When properly set up and organized, this process can take place as a scheduled event within your BBS, and requires relatively little maintenance or intervention on your part. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 39 ───────────────────────────────────────────────────────────────── INSTALLATION Before you run TNET (or any other BBS utility that works directly on your datafiles) for the first time, BACK UP. We'll say it again. BACK UP your important BBS files. UPGRADING FROM A PREVIOUS RELEASE If you already have a previous version of TNET running on your system, the upgrade to version 2.2 is straightforward. First, save a backup copy of your current TNET.EXE, and [hubname].CFG files. Then copy the new TNET.EXE in place of the old one. Even if you have run TNET before, you should reread this documentation to refresh your memory of TNET's features and functions, and to acquaint yourself with any new features which have been added in the current release. FIRST TIME INSTALLATION TNET is relatively straightforward to install and configure. However, network mail should be considered an advanced topic of BBS operation, and requires a thorough understanding of the concepts if you hope to use this program successfully. As such, there is no "Quick Installation" process for TNET, and you should not attempt to run this program until you have read, and understand, the documentation. Here is the installation procedure, step by step: 1. First, make a backup of your BBS files. 2. Extract the entire contents of TNET22.ZIP into your Startup Directory. 3. Print, read and save this documentation file. You will need to refer to it often during the initial setup and operation of your TNET network mail system. 4. Create your [hubname].CFG files Your next step is to create a [hubname].CFG file, using a text editor capable of saving files in plain ASCII format. Most of the information TNET requires at runtime is read directly from Wildcat's data files, with the remainder of the necessary information supplied by [hubname].CFG. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 40 ───────────────────────────────────────────────────────────────── TNET CONFIGURATION FILES TNET.CFG (optional) [Hubname].CFG (required) TNET looks for two configuration files when it starts up -- TNET.CFG and [Hubname].CFG where [Hubname] is the hub identifier specified on the TNET command line. Any options in [Hubname].CFG will override the corresponding option in TNET.CFG. This is useful if you call more than one hub for network mail -- the general options can be stored in TNET.CFG while the BBS-specific conference configuration information can be stored in individual hub configuration files. TNET uses a plain ASCII text file for its configuration information. It uses a set of keywords and options for defining conference numbers, paths to message packets, taglines, public/private mail, high message pointers, etc. The name of this file must match the "packet name" generated by your host's mail door (i.e. to process BIGBBS.QWK packets, you need a configuration file named BIGBBS.CFG). The following is a brief explanation of the keywords available in TNET's configuration file. A more complete explanation is provided in Chapter 4 -- Command Reference. Keywords marked [R] must be present in the CFG file; all others are optional and have suitable default values. TNET will ignore all lines beginning with a semicolon. Each keyword must be on a separate line. Spaces and indents make the configuration files easier for humans to read, but are ignored by TNET. Keyword Default Function SYSTEM [R] Type of your BBS system (WILDCAT2 or WILDCAT3) WORK WORK Work directory used by TNET QWKDIR current directory Directory to find QWK packets REPDIR current directory Directory to place REP packets LOGFILE None Name of log file PACKER PKZIP -es !, PKUNZIP -o ! Specify command lines for packer/unpacker APPEND N Append exported messages onto existing REP packet MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 41 ───────────────────────────────────────────────────────────────── ATFILTER Y Filter "@-variables" VERBOSE N Verbose log file entries TTAG Y Include the words "TNET 2.2" in tagline TCAN Empty "Trashcan" -- specify user(s) to exclude PRIVNAME Empty Username for which private messages are always exported TRANSLATE Empty Translate names, see Chapter 3 IMPTRANS for more information EXPTRANS LOCSYSOP HUBSYSOP IMPORTTAG None Tagline definition for imported messages EXPORTTAG None Tagline definition for exported messages CONF [R] Your local conference identifier HUBNUM [R] Your hub's conference number for above conference PRIVATE N Allow private messages in this conference TAG None Tagline letter for this conference NEXTMSG [R] Next message number to be exported by TNET MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 42 ───────────────────────────────────────────────────────────────── CHAPTER 7 -- TNET COMMAND REFERENCE TNET should always be run from your WILDCAT! home directory (the one that contains MAKEWILD.DAT). It must be run with a unique WCNODEID= setting, or you will defeat the file locking mechanism and corrupt your WILDCAT! databases. If you are running the single line version under DESQview, you MUST bring down WILDCAT! before running TNET. If you are using the Autonode feature on a multiline system, TNET will find a free node number to use. If you are using TNET with WILDCAT! version 2.x, you should start TNET from a valid, unused "Node Home" directory -- that is, one containing a valid CONFIGWC.BBS with a unique node ID number. COMMAND LINE PARAMETERS TNET can be run from the DOS command line, or from a batch file. Its command line format is the same in either case: TNET [EXPORT|IMPORT|HIGH] [hubname] EXPORT This command will tell TNET to extract all new mail from your message database and place it in a [hubname].REP packet to be uploaded to your hub. IMPORT This command will tell TNET to extract a QWK packet and insert all the messages in it into your message database. HIGH This command will tell TNET to set the message number in each conference listed in the .CFG file to the highest message number in the corresponding conference on the BBS. If you renumber your message base, you must use the HIGH command to tell TNET to reset all message pointers to the highest message in each conference, since the numbers will have changed. Just remember to do one last export before renumbering, as no messages will be exported immediately after running HIGH! KEYWORDS A TNET configuration file is a plain ASCII text file consisting of keywords, arguments, and optional comments, in the following format: <KEYWORD> = <OPTION> ; <COMMENT> <KEYWORD> = <OPTION1> , <OPTION2> ; <COMMENT> etc. Note the use of the equals sign as a delimiter between keywords MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 43 ───────────────────────────────────────────────────────────────── and options, and the comma to indicate additional options where required. Any text following a semicolon is treated as a comment line, and is ignored by TNET. If TNET encounters text in a config file which it is unable to recognize, it will abort with an error message indicating the line number and a brief description of the problem. The most common errors are misplaced or missing keywords or delimiters, or misspelled keywords. TNET looks for two configuration files when it starts up -- TNET.CFG and [Hubname].CFG where [Hubname] is the hub identifier specified on the TNET command line. Any options in [Hubname].CFG will override the corresponding option in TNET.CFG. SYSTEM This option must be set to WILDCAT3 or WILDCAT2. No other system types are supported. WORK This specifies the directory where TNET will place its work files. Make sure there are no files in this directory that you want to keep, because they will all be deleted as part of normal operation! By default, TNET will use WORK. You may specify another directory if you wish, or even a RAM drive for faster processing, so long as there is no possibility of another program or WILDCAT! node sharing the same directory during runtime. QWKDIR This specifies the directory where TNET will look to find QWK packets. This should generally be the same as the directory where your communications program places downloaded files. The default is the current directory. REPDIR This specifies the directory where TNET will place REP files to be uploaded. Make sure your communications program looks to this directory when uploading files. The default is the current directory. LOGFILE This specifies the file name where TNET will place a log of all network operations. This file is never deleted by TNET, so you will need to delete or archive this file periodically, as it can grow quite large, especially with the verbose logging option. PACKER This is the command line TNET will use when packing and unpacking mail packets. The example provided in the default TNET.CFG file supplied with this program should normally be left as is, unless you have a good reason MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 44 ───────────────────────────────────────────────────────────────── for changing it. APPEND When this option is set to Y, TNET will always append newly exported messages on to the end of an existing REP packet. When set to N (the default), TNET will always start a fresh REP packet whenever it exports mail, even if one already exists. Keep this option in mind when testing or running TNET outside a system event. You could over-write your REP file! ATFILTER When this option is set to Y, TNET will remove all @- variables of the form @STRING@, remove PCBoard @X color codes, and translate the "escape" character used in ANSI control strings to ` (reverse quote). PCBoard, WILDCAT!, and other BBS software use @-variables as substitution variables. Since their effect is unpredictable in messages, their use generally leads to confusion when used in a network environment. We recommend leaving this option as Y. VERBOSE When this option is set to Y, TNET will detail the To, From, and Subject lines of each message in the log file. Otherwise, just the conference summary totals are placed in the log file. TTAG Normally TNET identifies itself in all taglines appended by TNET. When this option is set to N, TNET will suppress the "TNET 2.2" part of the tagline. TCAN You can specify names of certain users whose messages you do not want imported or exported by TNET. Messages both To and From such users will not be moved. Note that return receipts generated by WILDCAT! Mail Room (if applicable) will never be exported into the network. PRIVNAME If you have set a particular conference in [hubname].CFG to "N" for private messages, but still want private messages from certain users to be exported, you can use this option to specify their names. Messages from users listed in the PRIVNAME section will always be exported regardless of the PRIVATE setting in each [Hubname].CFG conference definition. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 45 ───────────────────────────────────────────────────────────────── TRANSLATE TNET has the ability to translate user names on imported messages, exported messages, or both. Use these options with caution, and ONLY if absolutely necessary! There are five forms of translates: TRANSLATE = <localname>,<hubname> This option will translate all occurrences of <localname> in exported messages to <hubname>, and all occurrences of <hubname> in imported messages to <localname>. IMPTRANS = <localname>,<hubname> This option will translate all occurrences of <hubname> to <localname> in imported messages ONLY. EXPTRANS = <localname>,<hubname> This option will translate all occurrences of <localname> to <hubname> in exported messages ONLY. LOCSYSOP = <yourname> This is the same as TRANSLATE = SYSOP,<yourname> Use this option ONLY if you use the name SYSOP on your BBS instead of your real name. HUBSYSOP = <hubsysopname> This is the same as TRANSLATE = <hubsysopname>,SYSOP Use this option ONLY if your hub sysop uses the name SYSOP instead of his or her real name. IMPORTTAG/EXPORTTAG Since your hub's QWK mail door may not "tag" outgoing messages with their origin tagline, TNET must tag them during import to identify their source. This option is used to specify a tagline letter and tagline text for imported messages. For example: IMPORTTAG = T, Your Hub BBS Name and Phone Number identifies tagline type T as the above tagline text. Then for each conference which specifies tagline type T, the above tagline text will be placed at the bottom of imported messages if necessary. EXPORTTAG = T, Your BBS Name and Phone Number This is the tagline definition for exported messages. The tagline letter and tagline text are specified in the same way as in the IMPORTTAG option. In this case, the tagline text should identify your BBS name and MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 46 ───────────────────────────────────────────────────────────────── number so that outgoing messages can be properly identified. CONF This is the conference identifier to which the following four options will apply. Conference identifiers in Wildcat 3.x are numbered 0 through 999 (or whatever is the maximum number of conferences you have set in Makewild). Wildcat! 2.x conferences are numbered A through Z, and 26 through 255, if TOMCAT!'s extended conference structures are being used. If you are running TNET with WILDCAT! 2.x, please remember that A=0, B=1 and so on, when defining conferences. HUBNUM This is the hub conference number which corresponds to the above conference. Note that if your hub is a Wildcat 2.x system using TOMCAT, then A through Z are accepted as substitutes for 0 through 25, where A=0, B=1, and so forth. PRIVATE This yes/no option indicates whether or not private messages in this conference are exported by TNET. Note that if a message is from a user specified in the PRIVNAME section, it will always be exported regardless of this setting. TAG This is the tagline letter for this conference. See the description of the IMPORTTAG and EXPORTTAG options for more information. NEXTMSG This is the next message number to be exported by TNET. This option is automatically maintained by TNET and should not be changed under normal circumstances. The following is a sample [hubname].CFG configuration file: SYSTEM = WILDCAT3 WORK = C:\WC30\WCWORK\NODE1\TEMP QWKDIR = C:\QWK REPDIR = C:\REP LOGFILE = TNET.LOG PACKER = PKZIP -es ! , PKUNZIP -o ! APPEND = Y ATFILTER = Y VERBOSE = N TTAG = Y TCAN = BOTHERSOME USER PRIVNAME = GREG HEWGILL IMPORTTAG = T , Hub BBS Name and Phone Number EXPORTTAG = T , Your BBS Name and Phone Number MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 47 ───────────────────────────────────────────────────────────────── CONF = 5 ;This is a comment to identify local conf name HUBNUM = 105 ;This comment would identify hub conf name PRIVATE = Y TAG = T NEXTMSG = 0 CONF = 6 HUBNUM = 106 PRIVATE = N TAG = T NEXTMSG = 0 NETWORK SYSOP MESSAGE SUPPORT TNET supports "network sysop" messages. These are messages that will appear as a personal message to each sysop on a network. If, when importing a message, the message has a subject that begins with !NS! and the message is to ALL or NETWORK SYSOP, then the message will be posted to the sysop in addition to being posted normally. Depending on the BBS type, "posted to the sysop" will mean different things. If, when importing a message, the message has a subject that begins with !NS! but the message is NOT to ALL, then the subject is changed to start with (NS). This is so that, as replies to an !NS! message drift back up the network, their subjects are modified from !NS! to (NS). MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 48 ───────────────────────────────────────────────────────────────── CHAPTER 8 -- NETWORK MAIL CONCEPTS AND OPERATION QWK/REP mail, developed originally by Mark "Sparky" Herring, is the system of choice on a growing number of BBS networks, and is the mail system supported by TOMCAT and TNET. It adheres to a published, documented file format, and has the advantage of being supported by many third-party authors and BBS software programs. A wide selection of mail readers, mail doors, and message import/export utilities are available. TNET fully supports QWK/REP network mail for WILDCAT! and is compatible with RNet and QNet for PCBoard, and similar products for many other BBS software platforms. NET STATUS Because the QWK mail door serves a dual purpose (offline message reading for users, and network mail exchange for BBSs), the network mail software must have some way of differentiating between the two types of packets. There are three components to network status. The first component is security in the mail door itself. In ordinary circumstances, unless a user has sysop status, the mail door will not permit him to upload messages with a FROM: line different from his own login name. This is to prevent users posting messages under aliases and thus defeating the security of the message system. Obviously, however, a network node posting mail on a hub will need to be able to upload messages from its users without being granted sysop status on the host BBS. By giving network nodes "net status" in the mail door, the node BBS can post messages from any user name. The second component of net status involves the way in which the mail door identifies messages uploaded by network nodes. To prevent duplicate messages from circulating through the network over and over again, messages uploaded by a net status caller are "stamped" with a network address. This stamp prevents the node from downloading the same messages it just uploaded. This network address is generally placed somewhere in the message header and is not normally visible to callers or to the sysop. For copyright and security reasons, once again, a BBS sysop would usually want to restrict copying and transmission of his or her message base, granting such access only to those other sysops specifically authorized to participate in a mail network. The final component of net status is the way in which the mail door identifies the QWK message packet so that TNET and other network mail programs can safely import it. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 49 ───────────────────────────────────────────────────────────────── There are a variety of proprietary formats used by mail doors to signify net status in a mail packet. TNET must be able to detect net status before it will import a .QWK packet. If net status is not detected, TNET will exit to DOS with an error message. NETWORK TOPOLOGY AND ADMINISTRATION BBS networks usually have a 'tree' structure. Here's an example of a fairly typical setup: NET HUB | +--------+------------+----------+-----------+ | | | | | NODE NODE REGIONAL HUB NODE REGIONAL HUB | | +----+------+ +-----+-----+ | | | | | NODE NODE NODE NODE NODE A net hub would not call any other BBSs for mail; a regional hub calls the net hub to upload and download mail, and has nodes calling the regional to upload and download mail. Nodes call the net hub or regional hub only; they do not have any other boards calling them for mail. Real networks might have more or fewer levels in the tree. Every additional level means an extra time lag for messages to find their way up the tree to the net hub and back down the tree to the other nodes, and the most efficient topology is a subject of considerable debate and experimentation. NETIQUETTE If you're a network node, it's important to seek and follow the guidance of your hub sysop and network administration. Virtually all public echomail networks have formal or informal policies and regulations governing conduct of sysops and their users on the network. These issues, and the ones described below, are known collectively as "Netiquette". It's also important to let your users know what is expected of them in terms of language, topicality, and overall behavior on public echomail networks. Most networks distribute sample bulletins and conference lists, which should be available to your users. If you are acting as a network host or regional hub, you will probably need to assist your nodes with such matters as configuring their import/export software, making sure the MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 50 ───────────────────────────────────────────────────────────────── conference numbers on your BBS are being converted correctly to their own local conference numbers, advising your node sysops of the correct format for origin taglines, and monitoring general deportment of users. In order to simplify the task of configuring the node software, especially where a large number of conferences are available for echoing, it is customary for a hub sysop to assist node sysops by providing boilerplate configuration files showing names and numbers of message conferences. PROCESSING MAIL, STEP BY STEP Here's how a typical network mail transaction works, from the point of view of a network hub: You've set up a user account in WILDCAT! for a node called "BSCI BBS" with a security profile of NETSYSOP (or another security profile with net status toggled on in TCMAINT). Delbert, the sysop of BSCI BBS, now logs on as "BSCI BBS", enters the mail door and uploads the reply packet he prepared before calling. This reply packet consists of new messages exported from his own BBS, which TOMCAT unpacks and inserts into your message file. His last action is to download a new QWK packet for import into his BBS. Delbert then disconnects from your BBS, and processes his newly-received mail packet with TNET if he operates a WILDCAT! BBS, or its equivalent if he operates some other type of BBS software. The messages are inserted into the BSCI BBS message file(s), then Delbert restarts his BBS, and waits for the next mail processing event to roll around. Just before Delbert's next call, he exports all the new mail he and his callers have left on his BBS into a REP packet, using TNET. Export complete, he calls your BBS again, enters the TOMCAT mail door, uploads the replies, and downloads a fresh QWK packet. Finally, here is the typical procedure a node sysop would follow in creating and running a network mail event: 1. Export new local mail. Prepare a [hubname].REP packet ready to upload to your host by running: TNET EXPORT [hubname] TNET will call the config file matching the hubname. Do not add the .CFG extension to the hub name. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 51 ───────────────────────────────────────────────────────────────── TNET will then log its activity to the console and to the log file specified in [hubname].CFG. TNET will create [hubname].REP in the directory specified in the config file. It should be the directory in which Robocomm or your communications script expects to find the .REP file. 2. Collect new mail from your host. Call your hub, enter the mail door, upload your .REP packet, and then download a .QWK packet. Please remember to rename or delete the .REP packet after it has successfully been uploaded so you don't upload it again. The order in which you upload and download packets on your host is not critically important, but there are some factors which should be considered when doing a mail run. Most mail doors will allow you to upload a reply packet, then drop carrier as soon as the door indicates the packet has been successfully received. For this reason, doing the download first, then uploading and dropping carrier may save a few seconds on a long distance call, particularly if you are uploading large reply packets. On the other hand, phone line conditions in the real world may make this impractical -- if your packet download is subject to line noise hits and even disconnection, it may be better to upload your replies first to ensure they make their way into the network, then make whatever attempts are necessary to get an inbound QWK packet. If the download fails, the messages will still be on the host BBS for you to try again on your next call, but you know that your replies, at least, are now on their way to their destination. 3. Import new incoming mail. Import the newly downloaded messages into your BBS by calling TNET with the following parameters: TNET IMPORT [hubname] TNET will extract and index the .QWK packet you just received, and insert the messages into your database. A full report will appear on the local console and will also be logged to a disk file, if you have TNET's logging option turned on. 4. Cleanup and restart the BBS. Rename or delete your old .QWK and .REP packets, to prevent duplicate messages from re-entering the network. Then restart your BBS. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 52 ───────────────────────────────────────────────────────────────── MAINTENANCE ISSUES A typical general-interest public echomail network may have a hundred or more conferences available to its nodes. The management of such a large number of conferences, and messages, requires some planning and organization on the part of the sysop. The discussion which follows pertains mostly to public echomail networks, but many of these principles also apply to private, corporate or institutional message networks. DEFINING CONFERENCES The first issue to consider is configuring echomail conferences in MAKEWILD. There are a number of configuration items in the conference setup screens which will make echomail conference management much easier. It's important to set a maximum number of messages for echomail conferences, even if you do not do so for local conferences, as your message bases could otherwise grow out of control. Arriving at the right number of messages to keep depends on the traffic in each conference, and how long you'd like to keep messages around. For instance, if you want to keep messages for approximately 30 days, and the conference in question averages 10 messages a day, 300 messages would be a good starting point. The correct "Mail Type" for all TNET echomail conferences is always "Normal". The "Netmail" setting refers only to Fidonet netmail conferences and should never be used except for that special purpose. The "Max lines per message" setting should be set to 99 rather than the default of 150. While most BBS software is certainly capable of supporting messages longer than 99 lines, this figure is, by convention, the maximum message length on echomail networks. Always confirm with your hub sysop and network administrators that the network is capable of supporting longer messages before altering this figure. "Check valid name" should be set to "No", so your users can enter messages to network members whose names are not in your own local user database. "Allow message attachments" should be set to "No", as QWK/REP mail does not support file transfers through the network. "Allow return receipts" should also be set to "No". In order to preserve the continuity of threads in network conferences, the "Prompt to kill received messages" should be set to "No". Since the size of your message base is being maintained MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 53 ───────────────────────────────────────────────────────────────── by WILDCAT!, and since these are public conferences, it makes little sense to ask users to delete received messages. The "Allow private messages" and "Force all messages private" switches should be used with caution. Although TOMCAT and TNET both support the transmission of private messages from one system to another, this feature is not a reliable way of transmitting private mail when other systems are using other network mail software. The handling of private messages on other systems is highly unpredictable, and depends on individual system configuration and the varying capability of other network software to handle private messages. For example, messages toggled private on your system may end up toggled public on other systems, and could be read by anyone, not just those with sysop status. Even private mail can be read by sysops throughout the network, and should not be used to transmit sensitive or confidential information. It is generally undesirable to allow carbon copies in a network mail conference. Because all echomail messages are likely to be public in any event, multiple copies of the same message serve only to irritate other network sysops because of the added disk space and long distance transfer times these duplicate messages consume. The use of high ASCII characters and alias names in echomail conferences are generally governed by your network regulations, and should be configured accordingly. Remember to turn on conference access, as appropriate, for your callers' security profiles. Keep network regulations in mind when granting access -- some network conferences may have restricted access. For example, a "Sysops" conference may be limited to those individuals currently operating a bona fide BBS, and should be off-limits to ordinary callers. Some networks require that their "Network Admin" conferences be kept strictly private, for network sysops only; others require their administration to be conducted out in the open and available to all callers. Some "special interest" conferences may grant access by invitation or application only, or require legal proof of age before admission. If you have any questions about granting access to individual conferences, always consult your host sysop or network administrators for guidance. Finally, some public echomail networks have certain conferences set aside as "Read Only", meaning that only messages posted from the network hub are permitted to travel through the network. WILDCAT! version 3.02 and later has the capability to define such a conference as read-only. This means that, while TNET is capable MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 54 ───────────────────────────────────────────────────────────────── of importing mail into such a conference, no users -- not even the sysop -- would be able to enter or reply to messages in conferences configured this way. ORGANIZATION It is almost always a good idea to have a plan for organizing the naming and numbering of your echomail conferences. A well organized scheme for identifying conferences makes the task of maintenance easier for the sysop, and helps identify local and echomail conferences for your users. This becomes particularly important when you carry echomail conferences from more than one network, and from more than one hub. As networks grow and evolve, they inevitably add or delete conferences. There are few things more frustrating to network administrators and sysops than trying to track down which node is feeding duplicate messages into the network, or crossing messages from one conference or network to another, because someone has misconfigured a conference. The following guidelines should help prevent you from becoming one of the "culprits". As far as possible try to duplicate the general conference numbering scheme on your host's board. If you have, for example, 15 local conferences on your board, and plan to carry 20 or 30 echomail conferences as well, set the number of conferences in MAKEWILD to 200. Don't be afraid to leave gaps in your conference numbering. It won't hurt WILDCAT! or TNET a bit. You can then reserve conference numbers 0 to 100 for local message traffic, and conferences 101 and higher for network conferences. If your hub's conference numbers range from 1 to 99, it's a simple matter to add 100 to your hub's conference number when defining echomail conferences in MAKEWILD. So, your hub's conference number 38 becomes your conference number 138. Easy to set up, and easy to maintain. This numbering scheme gives you some room for expansion, and the additional space required for conference information in your user file should be more than outweighed by the ease and convenience with which you can add local and network conferences later on, if needed. When naming echomail conferences, it is useful to prefix the conference name with a one or two-letter abbreviation for the network name, particularly if you carry conferences with the same name from more than one network. For example, you may name the ILink WRITERS conference something like IL_Writers; or the SMARTNET Writers conference SN-Writers. In this way, the network identifier and conference names will show up in TOMCAT as well. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 55 ───────────────────────────────────────────────────────────────── This will help you and your users keep track of which conferences belong to which network. Finally, you should make the network guidelines and user regulations available to your callers as a bulletin or downloadable file, especially if they are new to echomail. RENUMBERING YOUR MESSAGE BASE From time to time, as a part of ordinary BBS maintenance, it may be necessary to renumber your message base. While the renumbering utility supplied with WILDCAT! BBS is capable of updating conference message pointers for your users, it has no way of updating your network configuration files. Every time you renumber your message bases, you must remember to update your network message pointers as well. It is vitally important, therefore, to consider the consequences of renumbering your message bases. This should not be done on a routine basis, at least for echomail conferences. When you do renumber your messages, you must organize the procedure so that TNET's configuration files are properly updated and no messages are lost or duplicated on their way to the hub. The correct procedure to follow when renumbering your message base is as follows: 1. Run TNET EXPORT [Hubname] to export any messages entered on your system. 2. Back up your message files and your TNET config files. 3. Renumber your message base(s). 4. Run TNET HIGH [Hubname] to adjust your NEXTMSG pointers. BACKUPS AND CRASHES Nobody likes to think about the possibility of system crashes, but they can happen from time to time, even to the most careful and well-organized sysop. TNET provides some measure of recovery by creating a backup of its config file(s) with the extension .CBK every time it is run. Your previous high message pointers can be restored by copying the .CBK file over the .CFG file. If TNET (or WILDCAT!, for that matter) is interrupted while it is in the process of writing to one of your message files (for example if there is a power failure or disk error, or if your machine locks up and requires a reboot), it is possible that the message file itself may become corrupted. WCREPAIR can usually MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 56 ───────────────────────────────────────────────────────────────── recover most or all of a damaged message file, but if the situation is hopeless, you may need to delete the offending MSGxxx.DAT and .IX files and let WILDCAT! re-initialize them. You will need then to renumber the conference (to reset your user's high message pointers for that conference), then run TNET HIGH to reset the NEXTMSG pointers. QWK mail packets are occasionally subject to corruption caused by line noise during the file transfer, or some other transient error on the host system. Unfortunately, even if the download fails for some reason, the mail door sometimes records the download as successful and updates your message pointers, causing you to lose incoming messages. It is possible with TOMCAT, Qmail and MarkMail to recover one's previous message pointers and re-download a packet, by making use of the .PTR (Qmail and TOMCAT) or .PTR file (MarkMail) included in your QWK packet. The method for restoring pointers is slightly different for each mail door, so you should acquaint yourself with the correct procedure for resetting message pointers for the particular mail door you use at your network hub. PERFORMANCE CONSIDERATIONS TNET employs file and record locking in the same manner as WILDCAT! and TOMCAT, and is safe to use on a multi-line system with other nodes active (providing, of course, that it is started with a node ID number not in use by any other active node). Because TNET's message importing and exporting routines are optimized for speed, however, you may notice slowdowns on other nodes, or excessive database lock retries ("gridlock") when callers are logging in or reading messages. This problem is more evident with DESQview on slow CPUs, and on small peer to peer networks where TNET is running on a server, than it would be when running on a LAN workstation. Slowdowns are also more noticeable on systems running the 2.x version of WILDCAT! than on version 3.x because version 2.x employed a single message database, whereas WILDCAT! 3.x uses a separate data file for each conference message base. The speed and throughput of your hardware has a large bearing on TNET's efficiency on a multi-line system. If you have lots of extended or expanded RAM, a large disk cache will substantially improve the performance of programs such as WILDCAT! and TNET, which access the disk frequently. If you find your system slows down unacceptably even with a disk cache, you may find it desirable to bring other nodes to DOS with MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 57 ───────────────────────────────────────────────────────────────── an event, do your TNET processing, then bring the system back up when your network mail import has been completed. The event batch files for your other nodes could use the WAIT! or WAITFOR! programs to wait a given amount of time, or your event batch files could check in a "goto" loop for the existence of a "puck file" created by the node doing the mail processing. Your mail processing batch file deletes this puck file when completed, and allows the other nodes to come up as soon as processing has completed. A number of third party utilities are available for download from MSI HQ! which may assist you in co-ordinating multiple-node events. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 58 ───────────────────────────────────────────────────────────────── APPENDIX A -- MESSAGE NETWORKS SUPPORTING TOMCAT AND TNET There are many public message networks available to choose from if you would like to join a network. The following is a short list of some major worldwide networks and their main hubs and BBS phone numbers: Network Major hubs Sysop Phone ILink Executive Network Andy Keeves (914) 667-4684 Microsellar Mark Rapp (201) 239-1346 U'NI-Net The Ledge Joe Sheppard (818) 352-3620 Rose Media Vic Kass (416) 733-2285 Intelec Intelec Online Cliff Watkins (516) 867-4448 Wildnet North Georgia Johnnie Yother (404) 226-4388 Throbnet Heart Throb BBS (adult) (908) 381-5682 More information files on public echomail networks are available for download from the MSI HQ! BBS. These information files are posted by representatives from the networks concerned, and their completeness and correctness is the responsibility of the network representatives concerned, not MSI. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 59 ───────────────────────────────────────────────────────────────── APPENDIX B -- TROUBLESHOOTING AND ERROR MESSAGES TOMCAT Fatal errors cause TOMCAT to exit to DOS, display a descriptive error message in bright white flashing letters on screen, and write the error message to the TOMCAT.ERR log in the \WC30 directory before returning control to Wildcat. These messages are usually self-explanatory. Complete lockups are rare, and usually indicate a hardware problem, or a TSR or other program interfering with TOMCAT. Two kinds of programs known to cause problems with TOMCAT and Wildcat are TSR file compressor-decompressor programs -- those which claim to increase hard disk space; and the resident MIRROR program with DOS 5. Most error messages are caused by configuration problems (for instance not enough file handles in CONFIG.SYS, or not having PKZIP.EXE and PKUNZIP.EXE in the path). A few error messages may be the result of a corrupted Wildcat database -- these are usually caused by running TOMCAT and the single line version of Wildcat in two DESQview windows at the same time, or by duplicating node ID numbers in the multi-line versions of Wildcat. Certain third party utilities which do not lock and unlock files properly may cause share violations or locking problems if run concurrently with TOMCAT. Some of the more common error messages, and their solutions, are: Unable to find <BBSID>.QWK after packing TOMCAT was unable to find your packer, or was unable to execute it for some reason. Usual cause: PKZIP/PKUNZIP (or other packer/unpacker utilities) were not in your DOS path or your \WC30 directory. Unable to open conference 0 Insufficient file handles. Edit your CONFIG.SYS and increase the number of file handles available in the FILES= line. Reboot your computer for the change to take effect, then try again. Recommended minimum setting: FILES = 40. Error writing MSGxxx.DAT Possible corrupted message file. Run WCREPAIR on the file indicated, and try again. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 60 ───────────────────────────────────────────────────────────────── Files left in work directory A system crash or duplicate node number has left files in \WC30\WCWORK\NODEx\TEMP -- delete the files in the work directory, recheck your configuration, and try again. TNET Fatal errors cause TNET to exit to DOS, display a descriptive error message in bright white flashing letters on screen, and write the error message to the TNET.ERR log in the \WC30 directory before returning control to Wildcat. These messages are usually self-explanatory. Complete lockups are rare, and usually indicate a hardware problem, or a TSR or other program interfering with TNET. Two kinds of programs known to cause problems with TNET and WILDCAT! are TSR file compressor-decompressor programs -- those which claim to increase hard disk space; and the resident MIRROR program with DOS 5. Most error messages are caused by configuration problems (for instance not enough file handles in CONFIG.SYS, or not having PKZIP.EXE and PKUNZIP.EXE in the path). A few error messages may be the result of a corrupted Wildcat database -- these are usually caused by running TNET and the single line version of Wildcat in two DESQview windows at the same time, or by duplicating node ID numbers in the multi-line versions of Wildcat. Certain third party utilities which do not lock and unlock files properly may cause share violations or locking problems if run concurrently with TNET. Some of the more common error messages, and their solutions, are: Unable to open conference 0 Insufficient file handles. Edit your CONFIG.SYS and increase the number of file handles available in the FILES= line. Reboot your computer for the change to take effect, then try again. Recommended minimum setting: FILES = 40. Error writing MSGxxx.DAT Possible corrupted message file. Run WCREPAIR on the file indicated, and try again. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 61 ───────────────────────────────────────────────────────────────── Files left in work directory A system crash or duplicate node number has left files in \WC30\WCWORK\NODEx\TEMP -- delete the files in the work directory, recheck your configuration, and try again. Packet does not have net status -- TNET cannot import TNET has not been able to recognize the network status identifiers in the .QWK packet. For security reasons, TNET will refuse to import non net-status QWK packets, and requires net status to be turned on by the sysop you are picking up your mail from. Could not find [Hubname].QWK This is an error message caused by the packer exiting with an error level indicating that it failing to execute for some reason. Usual causes: the QWK file does not exist (in other words, your communication program failed to download the file), or the mail packet is corrupted, or there was insufficient RAM to execute the packer. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 62 ───────────────────────────────────────────────────────────────── APPENDIX C - OFF-LINE XPRESS (OLX) Please encourage your callers to try Off-Line Xpress. This full- featured QWK packet reader from MSI works well with TOMCAT, and allows a wide range of configuration options in a well-designed, easy to use interface. Nearly every aspect of the program can be customized, from screen colors to "taglines". We've designed OLX to be easy and fun to use. It comes with a tutorial in the form of a specially prepared QWK mail packet which guides first-time users through the basic features and options they'll use when reading offline mail. Advanced users will enjoy the power and speed of OLX, too. Off-Line Xpress is full of useful and timesaving features. It offers full mouse support, online help, and a simple built-in text editor, which can be replaced with the editor or word processor of your choice. You can search for multiple strings of text in a message packet, and use advanced pick list options for repetitive tasks such as mailing lists and saving messages to disk. While OLX is designed as a serious productivity tool, we've included some other features to make mail reading fun and enjoyable. We'll leave it to you to find the puzzle game our programmer included in Off-Line Xpress ... meanwhile you can make full use of OLX's single-keystroke tagline stealing function. A Test Drive version of Off-Line Xpress is available for download from MSI HQ! BBS at 805-395-0650 (public access line) or 805-395-0250 (private line for registered WILDCAT! sysops only). The Test Drive version may be freely distributed. The fully registered version of Off-Line Xpress can be purchased from MSI for $40. Call our sales hotline at 1-800-999-9619 to order. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 63 ───────────────────────────────────────────────────────────────── APPENDIX D - FREQUENTLY ASKED QUESTIONS Question: What program should my callers and I use to read mail packets created by TOMCAT? Answer: TOMCAT will work with any QWK-compatible mail reader. You'll probably like Off-Line Xpress, though -- the test drive version is always available for download from the MSI HQ! BBS and may be freely distributed. Question: I get an error message sometimes which says "Unable to open <BBSID>.QWK after packing" Why? Answer: The usual cause for this message is not having your packer/unpacker utility in the path, or in the \WC30 directory where TOMCAT can find it. Another possible cause is running out of disk space on drive you have specified for your work directory. If you're using a Ramdisk, you may need to reduce the maximum number of messages per packet. This message can also occur if TOMCAT cannot run your packer for whatever reason -- you may need to turn Swap to Disk or EMS on in Makewild to free up enough memory for TOMCAT to execute the packer. Question: I allow unvalidated users to read mail, but they can't enter or reply to messages online. How can I prevent them from bypassing Wildcat! and entering messages through the TOMCAT door? Answer: TOMCAT reads the security profile definitions in MAKEWILD and generates dynamic menus in the same way Wildcat! does. A caller will not be shown (nor will he have access to) a menu function not permitted by his security level. In other words, if a caller is not allowed to leave messages online, he won't be allowed to upload replies to TOMCAT either. Question: My mail reader allows me to change the "from" field in the message header. Doesn't this mean I or my users can put fake names in the "from" part of messages upload to TOMCAT? Answer: No. TOMCAT prevents callers other than those with SYSOP security level from uploading messages not "from" the person logged on, unless they have NETSYSOP security. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 64 ───────────────────────────────────────────────────────────────── Question: I would like to exchange messages with a BBS belonging to my branch office in another state. How can I do this? Answer: TOMCAT fully supports 'net status' mail transfers. For full instructions on how to operate a network mail hub, please see the "Advanced Features" section of this document. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 65 ───────────────────────────────────────────────────────────────── APPENDIX E - GLOSSARY This is a glossary of terms commonly used by telecommunications enthusiasts, as well as words specific to offline mail reading and Bulletin Board Systems. We hope you find the information useful. ASCII American Standard Code for Information Exchange. A 7-bit binary code representation of letters, numbers and special characters. It is universally supported in computer data transfer. Baud Rate The number of discrete signal events per second occurring on a communications channel. It is often referred to as Bits per second (BPS) which is technically inaccurate but widely accepted. BBS Bulletin Board System. Buffer A memory area used for temporary storage during input/output operations. Bulletin Board System A host system, into which callers may dial with their modems to read and send electronic mail, upload and download files, and chat online with other callers. Byte A group of Bits acted upon as a group, which may have a readable ASCII value as a letter or number or some other coded meaning to the computer. It is commonly used to refer to 8-bit groups. 1 kilobyte = 1,024 bytes; 64K = 65,536 bytes or characters. Carrier A continuous frequency capable of being either modulated or impressed with another information-carrying signal. Carriers are generated and maintained by modems via the transmission lines of the telephone companies. MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 66 ───────────────────────────────────────────────────────────────── Conference An area of public messages on a Bulletin Board System, usually with a particular topic and, often, a conference host or moderator to guide the discussion. Also called Folder, SIG (for "Special Interest Group") or Echo. CPS Characters Per Second. A transfer rate estimated from the bit rate and length of each character. If each character is 8 bits long and includes a start and stop bit for Asynchronous transmission, each character needs 10 bits to be sent. At 2400 baud it is transmitted at approximately 240 CPS. CRC Cyclical Redundancy Check. An error-detection technique consisting of a cyclic algorithm performed on each "block" of data at the sending and receiving end of the transmission. As each block is received, the CRC value is checked against the CRC value sent along with the block. Many protocols including XMODEM- CRC and ARQ will request a resend until the block is received correctly. Download Receiving a file from a Bulletin Board System, using a terminal program (for example QModem) and a transfer protocol (for example Zmodem). DTE Data Terminal Equipment. The device that is the originator or destination of the data sent by a modem. DTR Data Terminal Ready. A signal generated by most modems indicating a connection between the DTE (computer) and the modem. When DTR is "high" the computer is connected. Data Compression Protocols Compression of data by the modem allows more information to be transferred in a shorter time frame. Protocols for data compression include CCITT V.42bis and MNP 5, MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 67 ───────────────────────────────────────────────────────────────── Echomail Public Message Conferences on a Bulletin Board System which are shared and distributed among other Bulletin Boards as part of an Echomail Network. Expanded Memory Extra memory (above 640k) on your XT or AT-compatible computer, which is installed with an EMS driver, and may be used by some programs to store data. Extended Memory Extra memory (above 640k) on your 80286 or 80386 compatible computer. Not normally usable by DOS applications, but may be configured as a virtual drive or a disk cache on an 80286 computer, or as Expanded Memory on an 80386 computer. Freeware Computer software which may be distributed on Bulletin Board Systems, and for which the author requests no license fee or registration fee. Host System Another name for a Bulletin Board System (BBS) Local Area Network (LAN) A group of computers joined with cables and software, allowing hard disks and other devices to be shared among many users. Mail Door A subsection of a Bulletin Board System which creates .QWK mail packets. Netmail Private electronic mail which is transmitted by a user calling one Bulletin Board System to another user calling a different Bulletin Board System. Packer A program to compress multiple files into a single file, such as PKZIP, ARC or LHARC MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 68 ───────────────────────────────────────────────────────────────── Packet A mail packet (with a .QWK extension) from a host system Protocol A system of rules and procedures governing communications between two devices. File transfer protocols in your communications program refer to a set of rules governing how error checking will be performed on blocks of data. Public Domain Computer software on which no copyright exists (usually by a specific statement to that effect by the author), and which may be freely used and distributed. Shareware Computer software which is distributed on the "Honor System", which may be freely copied and distributed, but for which a registration fee or payment is required for continued use beyond an initial evaluation period. Sysop The SYStem OPerator of a Bulletin Board System. The person responsible for setting up and maintaining the BBS. Thread A group of BBS messages and replies linked and sorted by topic. Unpacker A program to uncompress a file from a Packer Upload To transfer a file from your computer to another computer, using your terminal program (for example Qmodem) and a transfer protocol (for example Zmodem) MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 69 ───────────────────────────────────────────────────────────────── INDEX .CFG file . . . . . . . . . . . . . . . . . . . . . . . . 42, 55 Activity log . . . . . . . . . . . . . . . . . . . . . . 19, 35 Alias names . . . . . . . . . . . . . . . . . . . . . . . 23, 53 Allow message attachments . . . . . . . . . . . . . . . . . . 52 Allow private messages . . . . . . . . . . . . . . . . . 41, 53 Bulletins . . . . . . . . . . . . . . . . . . 12, 13, 19, 30, 49 Check valid name . . . . . . . . . . . . . . . . . . . . . . 52 Command line . . . . . . . . . . 13, 21, 26, 33, 34, 40, 42, 43 Comment line . . . . . . . . . . . . . . . . . . . . . . . . 43 Conference . 9, 12-14, 20, 22, 23, 26-31, 36, 40-42, 44-46, 49, 50, 52-56, 59, 60, 66 Configuration File . . . . . . . . . . . . . . . 14, 40, 42, 46 Console security . . . . . . . . . . . . . . . . . . . . 12, 33 Detailed logging . . . . . . . . . . . . . . . . . . . . 19, 20 Display files . . . . . . . . . . . . . . . . . . . . . . 13, 26 DOS hook . . . . . . . . . . . . . . . . . . . . . . . . 15, 34 DOS shell . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Download 5, 10, 13, 15, 16, 19-21, 27, 29, 30, 33-35, 38, 49-51, 56-58, 61, 62, 63, 65, 66 Duplicate messages . . . . . . . . . . . 20, 23, 48, 51, 53, 54 Echo-mail . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Echomail network . . . . . . . . . . . . . . . . 23, 24, 52, 67 Event . . . . . . . . . . . . . . 20, 35, 36, 38, 44, 50, 53, 57 Export . . . . . . . . . . . . . . . . 9, 35, 36, 42, 48-50, 55 Fatal error . . . . . . . . . . . . . . . . . . . . . . . . . 19 Fido . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 File transfer window . . . . . . . . . . . . . . . . . . . . 32 Force all messages private . . . . . . . . . . . . . . . . . 53 Help screen . . . . . . . . . . . . . . . . . . . . . . . . . 17 High ASCII characters . . . . . . . . . . . . . . . . . . . . 53 Home directory . . . . . . . . . . . . . . . . 9, 14-16, 18, 42 Hub . . . . . . . . . . . . . . . . . 9, 12, 35, 40-43, 45-56, 64 Import . . . . . . . . . . . . 9, 35, 38, 42, 45, 48-51, 57, 61 Installation . . . . . . . . . . . . . . . . . 4, 14-16, 26, 39 Keywords . . . . . . . . . . . . . . . . . . . . 18, 40, 42, 43 Local directory . . . . . . . . . . . . . . . . . . . 12, 18, 37 Local logon . . . . . . . . . . . . . . . . . . . . . . . . . 16 Mail door . 9-11, 15, 16, 22, 26, 35, 36, 38, 40, 45, 48, 50, 51, 56, 67 Mail type . . . . . . . . . . . . . . . . . . . . . . . . . . 52 MAIL.BAT . . . . . . . . . . . . . . . . . . . . 15, 16, 19, 34 MAKEWILD . . . . . . . . . . . 9, 12-15, 33, 42, 46, 52, 54, 63 Max lines per message . . . . . . . . . . . . . . . . . . . . 52 Maximum number of messages . . . . . . . . . . . . . . . 52, 63 Menu hook . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Modem . . . . . . . . . . . . . . . . . . . . . 5, 16, 23, 32, 66 Mouse . . . . . . . . . . . . . . . . . . . . . . . . . . 17, 62 Multi-line . . . . . . . . 5, 9, 15, 18, 19, 21, 33, 56, 59, 60 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 70 ───────────────────────────────────────────────────────────────── Net Status . . . . . . 9, 10, 21, 24, 35, 36, 38, 48-50, 61, 64 Netiquette . . . . . . . . . . . . . . . . . . . . . . . . . 49 NETSYSOP . . . . . . . . . . . . . . . . . . 24, 35, 36, 50, 63 Network sysop . . . . . . . . . . . . . . . . . . . . . . . . 47 New files . . . . . . . . . . . . . . . . . . . . . . 12, 19, 30 NEWFILES.DAT . . . . . . . . . . . . . . . . . . . . . . . . 12 Newsletter . . . . . . . . . . . . . . . . . . . . . . . . . 19 Node 9, 12, 24, 25, 32, 33, 36, 37, 42, 43, 48-50, 54, 56, 57, 59-61 Node directory . . . . . . . . . . . . . . . . . . . . 9, 12, 37 Node number . . . . . . . . . . . . . . . . . . 9, 32, 42, 60, 61 Off-line mail . . . . . . . . . . . . . . . . . . . . . . . . 11 Off-Line Xpress . . . . . . . . . . . . . . . . . 11, 37, 62, 63 Packer . 12, 21, 22, 27, 30, 32, 40, 43, 46, 59, 61, 63, 67, 68 Packet . 9-11, 13, 16, 19, 21-23, 27, 29, 30, 33-38, 40, 42, 44, 48-51, 56, 61-63, 68 Password . . . . . . . . . . . . . . . . . . . 6, 12, 21, 33, 34 Pointer file . . . . . . . . . . . . . . . . . . . . . . 29, 30 Prescan . . . . . . . . . . . . . . . . . . . . . 20, 21, 34, 35 Private messages . . . . . . . . . . . . . . 36, 41, 44, 46, 53 Prompt to kill received messages . . . . . . . . . . . . . . 52 Propeller . . . . . . . . . . . . . . . . . . . . . . . . . . 20 PTR files . . . . . . . . . . . . . . . . . . . . . . . . 12, 13 Qmodem . . . . . . . . . . . . . . . . . . . . 6, 24, 37, 66, 68 QWK . . . 6, 9-13, 18, 23, 24, 27, 29, 35-38, 40, 42, 43, 45, 46, 48-52, 56, 59, 61-63, 67, 68 Read only . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Regional Hub . . . . . . . . . . . . . . . . . . . . . . . . 49 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 42, 55 REP . . . . . . 10, 18, 27, 35, 36, 38, 40, 42-44, 46, 48, 50-52 Replies . . . . . . . . . . 9, 10, 20, 22, 36, 47, 50, 51, 63, 68 Reset pointers . . . . . . . . . . . . . . . . . . . . . 30, 31 Robocomm . . . . . . . . . . . . . . . . . . . . . . . . . 6, 51 Script . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Security level . . . . . . . . . . . . . . . . . . . . . 15, 63 Security profile . . . . . . . . . . . . 24, 32, 35, 36, 50, 63 Serial port . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Shell . . . . . . . . . . . . . . . . . . . . . . . . 12, 16, 27 Sort . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Startup directory . . . . . . . . . . . . . . . . . . . . 21, 39 Status line . . . . . . . . . . . . . . . . . . . . . . . . . 32 Swap . . . . . . . . . . . . . . . . . . . . . . . . 14, 15, 63 TCMAINT . . . . . . . . . . . 4, 12-14, 16-18, 23, 30, 33-37, 50 TCNODE.CFG . . . . . . . . . . . . . . . . . . . . . . . 19, 37 Technical Support . . . . . . . . . . . . . . . . . . . . 4, 6, 7 TEMP . . . . . . . . . . . . . . . . . . . . . . 18, 46, 60, 61 Terminal program . . . . . . . . . . . . . . . . . . . . 66, 68 Terminate . . . . . . . . . . . . . . . . . . . . . . . . . . 16 TNET . . . . . . . . . . . . 4-11, 23, 24, 35, 36, 38-58, 60, 61 TNET.CFG . . . . . . . . . . . . . . . . . . . . . . . . 40, 43 TOMCAT.BBS . . . . . . . . . . . . . . . . . . . . . . . . . 26 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 71 ───────────────────────────────────────────────────────────────── Tosser . . . . . . . . . . . . . . . . . . . . . . . . . 11, 24 Upload . . 9, 10, 13, 20, 23, 27, 29, 34, 38, 48-51, 63, 65, 68 WCNODEID . . . . . . . . . . . . . . . . . . . . . . . . 33, 42 Work directory . . . . . . . . . 18, 19, 21, 37, 40, 60, 61, 63 [Hubname].CFG . . . . . . . . . . . . . 9, 39, 40, 43, 44, 46, 51 [Hubname].QWK . . . . . . . . . . . . . . . . . . . . . . . . 61 [Hubname].REP . . . . . . . . . . . . . . . . . . . . 42, 50, 51 MUSTANG SOFTWARE, INC. TOMCAT 3.02/TNET 2.2 72 ─────────────────────────────────────────────────────────────────